date:20200523

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

2020-05-23 Thread Hervé Pagès


On 5/23/20 17:45, Gabriel Becker wrote:
Maybe my intuition is just 
different but when I collapse multiple character vectors together, I 
expect all the characters from each of those vectors to be in the 
resulting collapsed one.


Yes I'd expect that too. But the **collapse** operation in paste() has 
never been about collapsing **multiple** character vectors together. 
What it does is collapse the **single** character vector that comes out 
of the 'sep' operation.


So

  paste(x, y, z, sep="", collapse=",")

is analogous to

  sum(x + y + z)

The element-wise addition is analog to the 'sep' operation.
The sum() operation is analog to the 'collapse' operation.

H.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Surpising behavior when using an active binding as loop index in R 4.0.0

2020-05-23 Thread Deepayan Sarkar

A shorter reproducible example:

example(makeActiveBinding)
for (fred in 1:3) { 0 }
ls()

Both problems go away if you first do

compiler::enableJIT(2)

So looks like a bug in compiling the for loop.

-Deepayan

On Sat, May 23, 2020 at 5:45 PM Thomas Friedrichsmeier via R-devel
 wrote:
>
> Possibly just a symptom of the earlier behavior, but I'll amend my
> example, below, with an even more disturbing observation:
>
> Am Sat, 23 May 2020 13:19:24 +0200
> schrieb Thomas Friedrichsmeier via R-devel :
> [...]
> > Consider the code below:
> >
> > makeActiveBinding("i",
> >   function(value) {
> >   if (missing(value)) {
> >   x
> >   } else {
> >   print("set")
> >   x <<- value
> >   }
> >   }, globalenv())
> >
> > i <- 1 # output "set"
> > print(i)   # output [1] 1
> >
> > # Surprising behavior starts here:
> > for(i in 2:3) print(i) # output [1] "set"
> >#NULL
> >#NULL
> >
> > print(i)   # output NULL
> > print(x)   # output NULL
> >
> > i <- 4 # output "set"
> > print(i)   # ouput [1] 4
> > print(x)   # ouput [1] 4
>
> ls()
> # Error in ls() :
> #  Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>
> Regards
> Thomas
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] writeBin and short writes

2020-05-23 Thread frederik


Dear R-devel,

I'm curious why writeBin should always return NULL. Would anyone's code break 
if we made it return the number of bytes written? I'm not sure how else I'm 
supposed to use writeBin on a writable connection in non-blocking mode...

See attached.

Thank you,

Frederick
>From 3304e714f204c22d8e5c2ae93828683e04d1569d Mon Sep 17 00:00:00 2001
From: frede...@ofb.net
Date: Fri, 22 May 2020 15:42:37 -0700
Subject: [PATCH 1/1] Return number of bytes written

---
 src/main/connections.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/main/connections.c b/src/main/connections.c
index 88f082c696..2c47589018 100644
--- a/src/main/connections.c
+++ b/src/main/connections.c
@@ -4632,6 +4632,7 @@ SEXP attribute_hidden do_writebin(SEXP call, SEXP op, 
SEXP args, SEXP env)
} else {
size_t nwrite = con->write(buf, size, len, con);
if(nwrite < len) warning(_("problem writing to connection"));
+   ans = ScalarInteger(nwrite);
}
Free(buf);
 }
-- 
2.26.2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

2020-05-23 Thread Gabriel Becker

Brodie,

A good point, but more analogous to what I'm concerned with is

> sum(5, numeric(0))

[1] 5


Not 0 (the analogu of Herve's desired behavior).

Best,
~G

PS Brodie sorry for the double.

On Fri, May 22, 2020 at 6:12 PM brodie gaslam 
wrote:

> > On Friday, May 22, 2020, 6:16:45 PM EDT, Hervé Pagès <
> hpa...@fredhutch.org> wrote:
> >
> > Gabe,
> >
> > It's the current behavior of paste() that is a major source of bugs:
> >
> >   ## Add "rs" prefix to SNP ids and collapse them in a
> >   ## comma-separated string.
> >   collapse_snp_ids <- function(snp_ids)
> >   paste("rs", snp_ids, sep="", collapse=",")
> >
> >   snp_groups <- list(
> > group1=c(55, 22, 200),
> > group2=integer(0),
> > group3=c(99, 550)
> >   )
> >
> >   vapply(snp_groups, collapse_snp_ids, character(1))
> >   #group1group2group3
> >   # "rs55,rs22,rs200"  "rs"  "rs99,rs550"
> >
> > This has hit me so many times!
> >
> > Now with 'collapse0=TRUE', we finally have the opportunity to make it do
> > the right thing. Let's not miss that opportunity.
> >
> > Cheers,
> > H.
>
> FWIW what convinces me is consistency with other aggregating functions
> applied
> to zero length inputs:
>
> sum(numeric(0))
> ## [1] 0
>
> >
> >
> > On 5/22/20 11:26, Gabriel Becker wrote:
> > > I understand that this is consistent but it also strikes me as an
> > > enormous 'gotcha' of a magnitude that 'we' are trying to avoid/smooth
> > > over at this point in user-facing R space.
> > >
> > > For the record I'm not suggesting it should return something other than
> > > "", and in particular I'm not arguing that any call to paste /that does
> > > not return an error/ with non-NULL collapse should return a character
> > > vector of length one.
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

2020-05-23 Thread Gabriel Becker

Herve (et al.),

On Fri, May 22, 2020 at 3:16 PM Hervé Pagès  wrote:

> Gabe,
>
> It's the current behavior of paste() that is a major source of bugs:
>
>## Add "rs" prefix to SNP ids and collapse them in a
>## comma-separated string.
>collapse_snp_ids <- function(snp_ids)
>paste("rs", snp_ids, sep="", collapse=",")
>
>snp_groups <- list(
>  group1=c(55, 22, 200),
>  group2=integer(0),
>  group3=c(99, 550)
>)
>
>vapply(snp_groups, collapse_snp_ids, character(1))
>#group1group2group3
># "rs55,rs22,rs200"  "rs"  "rs99,rs550"
>
> This has hit me so many times!
>
> Now with 'collapse0=TRUE', we finally have the opportunity to make it do
> the right thing. Let's not miss that opportunity.
>

I see what you're saying, but I don' know. Maybe my intuition is just
different but when I collapse multiple character vectors together, I
expect all the characters from each of those vectors to be in the resulting
collapsed one. In your example its a string literal tot be added
elementwise to the prefix, but what if it is another vector of length > 1.
Wouldn't it be strange that all those values are wiped and absent from the
resulting string? Maybe it's just me. like for paste(x,y,z, sep ="",
collapse = ", ", recycle0=TRUE) if length(y) is 0, it literally makes no
difference when x and z are.

I seem to be being largely outvoted anyway though, so we will see what
Martin and others who may pop up might think, but I raised the points I
wanted to raise so we'll see where things ultimately fall.

~G



>
> Cheers,
> H.
>
>
> On 5/22/20 11:26, Gabriel Becker wrote:
> > I understand that this is consistent but it also strikes me as an
> > enormous 'gotcha' of a magnitude that 'we' are trying to avoid/smooth
> > over at this point in user-facing R space.
> >
> > For the record I'm not suggesting it should return something other than
> > "", and in particular I'm not arguing that any call to paste /that does
> > not return an error/ with non-NULL collapse should return a character
> > vector of length one.
> >
> > Rather I'm pointing out that it could (perhaps should, imo) simply be an
> > error, which is also consistent, in the strict sense, with
> > previous behavior in that it is the developer simply declining to extend
> > the recycle0 argument to the full parameter space (there is no rule that
> > says we must do so, arguments whose use is incompatible with other
> > arguments can be reasonable and called for).
> >
> > I don't feel feel super strongly that reeturning "" in this and similar
> > cases horrible and should never happen, but i'd bet dollars to donuts
> > that to the extent that behavior occurs it will be a disproportionately
> > major source of bugs, and i think thats at least worth considering in
> > addition to pure consistency.
> >
> > ~G
> >
> > On Fri, May 22, 2020 at 9:50 AM William Dunlap  > > wrote:
> >
> > I agree with Herve, processing collapse happens last so
> > collapse=non-NULL always leads to a single character string being
> > returned, the same as paste(collapse="").  See the altPaste function
> > I posted yesterday.
> >
> > Bill Dunlap
> > TIBCO Software
> > wdunlap tibco.com
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__tibco.com=DwMFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Z1o-HO3_OqxOR9LaRguGvnG7X4vF_z1_q13I7zmjcfY=7ZT1IjmexPqsDBhrV3NspPTr8M8XiMweEwJWErgAlqw=
> >
> >
> >
> > On Fri, May 22, 2020 at 9:12 AM Hervé Pagès  > > wrote:
> >
> > I think that
> >
> >  paste(c("a", "b"), NULL, c("c",  "d"),  sep = " ", collapse
> > = ",",
> > recycle0=TRUE)
> >
> > should just return an empty string and don't see why it needs to
> > emit a
> > warning or raise an error. To me it does exactly what the user
> > is asking
> > for, which is to change how the 3 arguments are recycled
> > **before** the
> > 'sep' operation.
> >
> > The 'recycle0' argument has no business in the 'collapse'
> operation
> > (which comes after the 'sep' operation): this operation still
> > behaves
> > like it always had.
> >
> > That's all there is to it.
> >
> > H.
> >
> >
> > On 5/22/20 03:00, Gabriel Becker wrote:
> >  > Hi Martin et al,
> >  >
> >  >
> >  >
> >  > On Thu, May 21, 2020 at 9:42 AM Martin Maechler
> >  >  > 
> >  > >> wrote:
> >  >
> >  >  > Hervé Pagès
> >  >  > on Fri, 15 May 2020 13:44:28 -0700 writes:
> >  >
> >  >  > There is still the situation where **both** 'sep'
> and
> >

Re: [Rd] dbinom link

2020-05-23 Thread Martin Maechler

> Hilmar Berger 
> on Mon, 18 May 2020 11:25:56 +0200 writes:

> What about using the Wayback Machine archive ? The web archive should be 
> more stable than other links which also might disappear in the future.

> E.g. 
> 
https://web.archive.org/web/20070610002602/http://www.herine.net/stat/software/dbinom.html

> , which also links to an archived copy of the PDF.

> Best regards,
> Hilmar

Thank you, Hilmar;  I have been aware of the web.archive ... but
I already had 3 (very slightly different) versions of the report
on my computer (from "way back" ..).

We've now added the "best" (and most recent, 2002) to the R-project website, 
and amended the 'Binomial'  help page to include the new link:  It
now says (in R-devel and 'R 4.0.0 patched') :

  Source:

 For dbinom a saddle-point expansion is used: see

 Catherine Loader (2000). _Fast and Accurate Computation of
 Binomial Probabilities_; available as https://www.r-project.org/doc/reports/CLoader-dbinom-2002.pdf>

Best regards,
Martin



> On 18.05.20 10:57, peter dalgaard wrote:
>> In principle a good idea, but I'm not sure the whereabouts of Catherine 
Loader are known at this point. Last peeps from her on the net seem to be about 
a decade old.
>> 
>> .pd
>> 
>>> On 18 May 2020, at 10:31 , Abby Spurdle  wrote:
>>> 
>>> This has come up before.
>>> 
>>> Here's the last time:
>>> https://stat.ethz.ch/pipermail/r-devel/2019-March/077478.html
>>> 
>>> I guess my answer to the following the question...
>>> 
>>> Perhaps we should ask permission to
>>> nail the thing down somewhere on r-project.org?
>>> 
>>> ...would be, to reproduce it somewhere.
>>> And then update the link in the binom help file.
>>> 
>>> Given that the article was previously available freely (with no
>>> apparent restrictions on reproducing it), and that the author has
>>> significant published works which are open access, I'd be surprised if
>>> there's any objection to reproducing it.
>>> 
>>> 
>>> On Mon, May 18, 2020 at 8:01 PM Koenker, Roger W 
 wrote:
 FWIW the link from ?dbinom to the Loader paper on Binomials is broken 
but the paper seems to be
 available here:   
https://octave.1599824.n4.nabble.com/attachment/3829107/0/loader2000Fast.pdf
 
 Roger Koenker
 r.koen...@ucl.ac.uk
 Honorary Professor of Economics
 Department of Economics, UCL
 Emeritus Professor of Economics
 and Statistics, UIUC
 
 
 
 [[alternative HTML version deleted]]
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] dbinom link

2020-05-23 Thread Hilmar Berger

What about using the Wayback Machine archive ? The web archive should be
more stable than other links which also might disappear in the future.

E.g.
https://web.archive.org/web/20070610002602/http://www.herine.net/stat/software/dbinom.html

, which also links to an archived copy of the PDF.

Best regards,

Hilmar

On 18.05.20 10:57, peter dalgaard wrote:

In principle a good idea, but I'm not sure the whereabouts of Catherine Loader
are known at this point. Last peeps from her on the net seem to be about a
decade old.

.pd

On 18 May 2020, at 10:31 , Abby Spurdle wrote:

This has come up before.

Here's the last time:
https://stat.ethz.ch/pipermail/r-devel/2019-March/077478.html

I guess my answer to the following the question...

Perhaps we should ask permission to
nail the thing down somewhere on r-project.org?

...would be, to reproduce it somewhere.
And then update the link in the binom help file.

Given that the article was previously available freely (with no
apparent restrictions on reproducing it), and that the author has
significant published works which are open access, I'd be surprised if
there's any objection to reproducing it.

On Mon, May 18, 2020 at 8:01 PM Koenker, Roger W wrote:

FWIW the link from ?dbinom to the Loader paper on Binomials is broken but the
paper seems to be
available here:
https://octave.1599824.n4.nabble.com/attachment/3829107/0/loader2000Fast.pdf

Roger Koenker
r.koen...@ucl.ac.uk
Honorary Professor of Economics
Department of Economics, UCL
Emeritus Professor of Economics
and Statistics, UIUC

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] ftable <-> data.frame etc {was "justify hard coded in format.ftable"}

2020-05-23 Thread Gabor Grothendieck



That's not the problem.  The problem is that if you have

   ft <- ftable(UCBAdmissions, row.vars = 3:2)
   ft
   ## Admit Admitted Rejected
   ## Dept Gender
   ## AMale  512  313
   ##  Female 89   19
   ## BMale  353  207
   ##  Female 178
   ## CMale  120  205
  ## ... etc ...

then as.data.frame(ft) gives a deconstructed 24x4 data.frame
like this:

  as.data.frame(ft)
  ##Dept GenderAdmit Freq
  ## 1 A   Male Admitted  512
  ## 2 B   Male Admitted  353
  ## 3 C   Male Admitted  120
  ## 4 D   Male Admitted  138
  ## ... etc ...

which is fine but it does not address the problem here.  The
problem here is that we want a a usable data.frame
having columns that correspond to ft.  We want this 12x4
data.frame:

  ##Dept Gender Admitted Rejected
  ## 1 A   Male  512  313
  ## 2 A Female   89   19
  ## 3 B   Male  353  207
  ## 4 B Female   178
  ## ... etc ...

The links I provided already pointed to the code below which
someone posted on SO and solves the problem but I would
have thought this would be easy to do in base R and natural
to provide.

  ftable2df <- function(mydata) {
ifelse(class(mydata) == "ftable",
mydata <- mydata, mydata <- ftable(mydata))
dfrows <- rev(expand.grid(rev(attr(mydata, "row.vars"
dfcols <- as.data.frame.matrix(mydata)
names(dfcols) <- do.call(
  paste, c(rev(expand.grid(rev(attr(mydata, "col.vars", sep = "_"))
cbind(dfrows, dfcols)
  }
  ftable2df(ft)
  ##Dept Gender Admitted Rejected
  ## 1 A   Male  512  313
  ## 2 A Female   89   19
  ## 3 B   Male  353  207
  ## 4 B Female   178
  ## ... etc ...

 Fri, May 15, 2020 at 12:25 PM Martin Maechler
 wrote:
>
> > Gabor Grothendieck
> > on Thu, 14 May 2020 06:56:06 -0400 writes:
>
> > If you are looking at ftable could you also consider adding
> > a way to convert an ftable into a usable data.frame such as
> > the ftable2df function defined here:
>
> > https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126
>
> > and there is an example of using it here:
>
> > https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756
>
> > Being able to move back and forth between various base class representations
> > seems like something that would be natural to provide.
>
> Sure!
>
> But there is already an  as.data.frame() method for "ftable",
> {and I would not want theif(! .. ftable)  ftable(x)  part anyway.
>
> What I think many useRs / programmeRs  very often forget about
> is more-than-2-dimensional arrays {which *are* at the beginning
> of that SO question} and that these are often by far the most
> efficient data structure (rather than the corresponding data frames).
>
> and even less people forget that a "table" in base R is just a
> special case of a 1-D, 2-D, 3-D,  array.
> (Semantically a special case: "array" with non-negative integer content
>
> I'd claim that everything you here ("move back and forth between
> ...") is already there in the "ftable" implementation in stats,
> notably in the source file  src/library/stats/R/ftable.R
>  -> https://svn.r-project.org/R/trunk/src/library/stats/R/ftable.R
>
> The problem may be in
>
> 1) too sparse documentation about the close relations
>"ftable" <-> "array" <-> "table" <-> "data.frame"
>
> 2) people not thinking often enough about more-than-2D-arrays and the
>   special corresponding class "table" in R.
>
> To start with one:
>
> > str(UCBAdmissions)
>  'table' num [1:2, 1:2, 1:6] 512 313 89 19 353 207 17 8 120 205 ...
>  - attr(*, "dimnames")=List of 3
>   ..$ Admit : chr [1:2] "Admitted" "Rejected"
>   ..$ Gender: chr [1:2] "Male" "Female"
>   ..$ Dept  : chr [1:6] "A" "B" "C" "D" ...
> >
>
> and look at the *examples* in the help files and the S3 methods
>
> methods(class = "ftable")
> [1] as.data.frame as.matrix as.table  formathead  
> print
> [7] tail
> see '?methods' for accessing help and source code
> > methods(class = "table")
>  [1] [ aperm as.data.frame Axis  coerce
> initialize
>  [7] lines plot  pointsprint show  
> slotsFromS3
> [13] summary   tail
> see '?methods' for accessing help and source code
> >
>
> ... need to close now, there's more to be said ...
>
>
>
> > On Thu, May 14, 2020 at 5:32 AM Martin Maechler
> >  wrote:
> >>
> >> > SOEIRO Thomas
> >> > on Wed, 13 May 2020 20:27:15 + writes:
> >>
> >> > Dear all,
> >> > I haven't received any feedback so far on my proposal to make 
> "justify" argument available in stats:::format.ftable
> >>
> >> > Is this list the appropriate place for this kind of

Re: [Rd] round() and signif() do not check argument names when a single argument is given

2020-05-23 Thread Shane Mueller

On Fri, May 22, 2020 at 9:55 PM David Winsemius 
wrote:

> The premise in the first few lines of your preamble is at odds (in the
> logical sense) with my understanding of primitive function behavior. Try:
>
> data.frame(x=1:2,y=letters[1:2])[j=2, i=1]
>
> David
>

I had never seen naming indexes of the [] operator.  The documentation of
[] indicates that it does argument matching in a non-standard way,
recommends against doing it, and states the [.data.frame behavior used in
this example is 'undocumented'.  In the example above a warning is thrown
as well.

Here is the [] documentation:

Argument matching
> Note that these operations do not match their index arguments in the
> standard way: argument names are ignored and positional matching only is
> used. So m[j = 2, i = 1] is equivalent to m[2, 1] and not to m[1, 2].
>
> This may not be true for methods defined for them; for example it is not
> true for the data.frame methods described in [.data.frame which warn if i
> or j is named and have undocumented behaviour in that case.
>
> To avoid confusion, do not name index arguments (but drop and exact must
> be named).
>

For the data frames operator [], i and j appear to be named and used
arguments, as the following causes an unused argument error for k:
data.frame(x=1:2,y=letters[1:2])[j=2, k=1]

The analog for round() would be indexing with something like  [k=1,] alone,
which causes an unused argument error error for data frames, which is what
I'm suggesting round(banana=3.5) should do.   (note it works for matrix as
documented).

Best,
Shane

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] GCC warning

2020-05-23 Thread Adrian Dușa

On Sat, May 23, 2020 at 10:01 AM Prof Brian Ripley 
wrote:

> On 23/05/2020 07:38, Simon Urbanek wrote:
> > Adrian,
> >
> > newer compilers are better at finding bugs - you may want to read the
> full trace of the error, it tells you that you likely have a memory
> overflow when using strncpy() in your package. You should check whether it
> is right. Unfortunately we can’t help you more specifically, because I
> don't see any link to what you submitted so can’t look at the code involved.
>
> NB: debian-gcc on CRAN does have the latest version of gcc (10.1) and
> the link would likely have given fuller details (such links are provided
> on CRAN report pages but I do not know for submissions).
>
> gcc does sometimes give false alarms here (there is one for R with gcc
>  >= 9 and another for gcc >= 10) but see
>
> https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
> .  Most can easily be workaround by cleaner code.
>

Oh, of course, apologies for the oversight, these are the links:

"package QCA_3.8.tar.gz does not pass the incoming checks automatically,
please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/QCA_3.8_20200521_185504/Windows/00check.log
>
Status: 1 NOTE
Debian: <
https://win-builder.r-project.org/incoming_pretest/QCA_3.8_20200521_185504/Debian/00check.log
>
Status: 1 WARNING, 1 NOTE"

I only now realised the most relevant link was down below, after "last
released version's CRAN status" (where I mistakenly stopped reading
further):

"More details are given in the directory:
"

This is indeed very informative, and points to specific parts of the code
that seem to be responsible with the warning.
Thank you both very much for the pointers, I now at least know what should
I try to fix.

Best wishes,
Adrian

-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R-devel's ...names() questions

2020-05-23 Thread Martin Maechler

> William Dunlap via R-devel 
> on Fri, 22 May 2020 11:53:12 -0700 writes:

> Am am missing something or does the new ...names() in R-devel not work
> right?

No, you are not missing anything, and you are right.
Thank you for the report!

Martin

>> a <- function(x, ...) ...names()
>> a(a=stop("a"), b=stop("b"))
> [1] "a" ""
>> a(stop("x"), stop("unnamed"), c=stop("c"), d=stop("d"))
> [1] NA "" ""

>> version
> _
> platform   x86_64-pc-linux-gnu
> arch   x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status Under development (unstable)
> major  4
> minor  1.0
> year   2020
> month  05
> day19
> svn rev78492
> language   R
> version.string R Under development (unstable) (2020-05-19 r78492)
> nickname   Unsuffered Consequences

> The following seems to do the right thing
> alt...names <- function() evalq(names(substitute(...())),
> envir=parent.frame())

> However I wonder if it would be better to give the user a function, say
> ...args_unevaluated(...) to get the unevaluated ... arguments directlly
> without having to know about the substitute(...()) trick.   Then the user
> could get the length, the n'th, or the names using the usual length(), [[,
> and names() functions instead of ...length(), ...elt(), and ...names().

> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com

> [[alternative HTML version deleted]]

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Compatibility issues caused by new simplify argument in apply function

2020-05-23 Thread Martin Maechler

> Lukas Lehnert via R-devel 
> on Fri, 22 May 2020 12:26:05 +0200 writes:

> Dear R Developers,
> the new  simplify argument in apply causes that my package (hsdar) does 
not 
> pass the 
> checks in R-devel.

> The workaround, Kurt Hornik send me, is working for the R-code:
> if("simplify" %in% names(formals(base::apply))) 
> do something 
> else 
> do something else

> Unfortunately, I cannot conditionalize the man pages of the functions. 

Why should you do that?   In other words:  Why change the
argument list of your function(s) ?

That \Sexpr{} does not work as a section is "obvious" (for some),
but I really don't see why you should change the argument list
or defaults of your hdara package functions at all.

Martin Maechler
ETH Zurich  and  R Core

> I get the message 
> that "applySpeclib.Rd:12-14: Section \Sexpr is unrecognized and will be 
> dropped" if I try to 
> dynamically define the entire usage section. If I try to use \Sexpr 
inside the 
> \usage section, 
> I get the following warning: "applySpeclib.Rd:13-15: Tag \Sexpr is 
invalid in 
> a \usage block"

> Does anybody have an idea how to proceed. The full code is available 
below.

> Thanks

> Lukas


> *1. Code for full usage section:*
> ..
> \description{
> Apply function over all spectra or a subset of spectra in a 
\code{Speclib}.
> }

> \Sexpr[echo=TRUE,results=rd,stage=install]{
> hsdar:::.applyInHelp1("Speclib", usage = TRUE)
> }

> \arguments{
> ..

> *Function .applyInHelp1*
> .applyInHelp1 <- function(fun_name, usage)
> {
> if (usage)
> {
> if ("simplify" %in% names(formals(base::apply))) 
> {
> return(paste0("\\usage{\n",
> "\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ..., 
> simplify = TRUE)\n",
> "}"))
> } else {
> return(paste0("\\usage{\n",
> "\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...)
> \n",
> "}"))
> }
> } else {
> if ("simplify" %in% names(formals(base::apply))) 
> {
> return("}\n\\item{simplify}{Currently ignored")
> } else {
> return("")
> }
> }
> }


> *2. Using \Sexpr inside the \usage block*
> \usage{
> \S4method{apply}{Speclib}(X, FUN, bySI = NULL, ...
> \Sexpr[echo=TRUE,results=rd,stage=install]{
> hsdar:::.applyInHelp2(usage = TRUE)
> }
> )
> }


> *Function .applyInHelp2*
> .applyInHelp2 <- function(usage)
> {
> if (usage)
> {
> if ("simplify" %in% names(formals(base::apply))) 
> {
> return(", simplify = TRUE)")
> } 
> } else {
> if ("simplify" %in% names(formals(base::apply))) 
> {
> return("}\n\\item{simplify}{Currently ignored")
> } else {
> return("")
> }
> }
> }

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Surpising behavior when using an active binding as loop index in R 4.0.0

2020-05-23 Thread Thomas Friedrichsmeier via R-devel

Possibly just a symptom of the earlier behavior, but I'll amend my
example, below, with an even more disturbing observation:

Am Sat, 23 May 2020 13:19:24 +0200
schrieb Thomas Friedrichsmeier via R-devel :
[...]
> Consider the code below:
> 
> makeActiveBinding("i", 
>   function(value) {
>   if (missing(value)) {
>   x
>   } else {
>   print("set")
>   x <<- value
>   }
>   }, globalenv())
> 
> i <- 1 # output "set"
> print(i)   # output [1] 1
> 
> # Surprising behavior starts here:
> for(i in 2:3) print(i) # output [1] "set"
>#NULL
>#NULL
> 
> print(i)   # output NULL
> print(x)   # output NULL
> 
> i <- 4 # output "set"
> print(i)   # ouput [1] 4
> print(x)   # ouput [1] 4

ls()
# Error in ls() : 
#  Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'

Regards
Thomas


pgpq_90MQ_lQD.pgp
Description: Digitale Signatur von OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Should 0L * NA_integer_ be 0L?

2020-05-23 Thread Michael Chirico

OK, so maybe one way to paraphrase:

For R, the boundedness of integer vectors is an implementation detail,
rather than a deeper mathematical fact that can be exploited for this
case.

One might also expect then that overflow wouldn't result in NA, but
rather automatically cast up to numeric? But that this doesn't happen
for efficiency reasons?

Would it make any sense to have a different carveout for the logical
case? For logical, storage as integer might be seen as a similar type
of implementation detail (though if we're being this strict, the
question arises of what multiplication of logical values even means).

FALSE * NA = 0L


On Sat, May 23, 2020 at 6:49 PM Martin Maechler
 wrote:
>
> > Michael Chirico
> > on Sat, 23 May 2020 18:08:22 +0800 writes:
>
> > I don't see this specific case documented anywhere (I also tried to 
> search
> > the r-devel archives, as well as I could); the only close reference
> > mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this
> > snippet from R-lang:
>
> > In cases where the result of the operation would be the same for all
> >> possible values the NA could take, the operation may return this value.
> >>
>
> > This begs the question -- shouldn't 0L * NA_integer_ be 0L?
>
> > Because this is an integer operation, and according to this definition 
> of
> > NA:
>
> > Missing values in the statistical sense, that is, variables whose value
> >> is not known, have the value @code{NA}
> >>
>
> > NA_integer_ should be an unknown integer value between -2^31+1 and 
> 2^31-1.
> > Multiplying any of these values by 0 results in 0 -- that is, the 
> result of
> > the operation would be 0 for all possible values the NA could take.
>
>
> > This came up from what seems like an inconsistency to me:
>
> > all(NA, FALSE)
> > # [1] FALSE
> > NA * FALSE
> > # [1] NA
>
> > I agree with all(NA, FALSE) being FALSE because we know for sure that 
> all
> > cannot be true. The same can be said of the multiplication -- whether NA
> > represents TRUE or FALSE, the resulting value is 0 (FALSE).
>
> > I also agree with the numeric case, FWIW: NA_real_ * 0 has to be 
> NA_real_,
> > because NA_real_ could be Inf or NaN, for both of which multiplication 
> by 0
> > gives NaN, hence 0 * NA_real_ is either 0 or NaN, hence it must be 
> NA_real_.
>
> I agree about almost everything you say above. ...
> but possibly the main conclusion.
>
> The problem with your proposed change would be that  integer
> arithmetic gives a different result than the corresponding
> "numeric" computation.
> (I don't remember other such cases in R, at least as long as the
>  integer arithmetic does not overflow.)
>
> One principle to decided such problems in S and R has been that
> the user should typically *not* have to know if their data is
> stored in float/double or in integer, and the results should be the same
> (possibly apart from staying integer for some operations).
>
>
> {{Note that there are also situations were it's really
>   undesirable that0 * NA   does *not* give 0 (but NA);
>   notably in sparse matrix operations where you'd very often can
>   now that NA was not Inf (or NaN) and you really would like to
>   preserve sparseness ...}}
>
>
> > [[alternative HTML version deleted]]
>
> (as you did not use plain text ..)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Surpising behavior when using an active binding as loop index in R 4.0.0

2020-05-23 Thread Thomas Friedrichsmeier via R-devel

Hi,

I stumbled upon a surprising behavior when using an active binding as a
loop index variable in R 4.0.0. In contrast, the behavior observed in R
3.6.1 is in line with my expectations.

Consider the code below:

makeActiveBinding("i", 
function(value) {
if (missing(value)) {
x
} else {
print("set")
x <<- value
}
}, globalenv())

i <- 1 # output "set"
print(i)   # output [1] 1

# Surprising behavior starts here:
for(i in 2:3) print(i) # output [1] "set"
   #NULL
   #NULL

print(i)   # output NULL
print(x)   # output NULL

i <- 4 # output "set"
print(i)   # ouput [1] 4
print(x)   # ouput [1] 4

Regards
Thomas


pgpyKwfk1KgEj.pgp
Description: Digitale Signatur von OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Should 0L * NA_integer_ be 0L?

2020-05-23 Thread Martin Maechler

> Michael Chirico 
> on Sat, 23 May 2020 18:08:22 +0800 writes:

> I don't see this specific case documented anywhere (I also tried to search
> the r-devel archives, as well as I could); the only close reference
> mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this
> snippet from R-lang:

> In cases where the result of the operation would be the same for all
>> possible values the NA could take, the operation may return this value.
>> 

> This begs the question -- shouldn't 0L * NA_integer_ be 0L?

> Because this is an integer operation, and according to this definition of
> NA:

> Missing values in the statistical sense, that is, variables whose value
>> is not known, have the value @code{NA}
>> 

> NA_integer_ should be an unknown integer value between -2^31+1 and 2^31-1.
> Multiplying any of these values by 0 results in 0 -- that is, the result 
of
> the operation would be 0 for all possible values the NA could take.


> This came up from what seems like an inconsistency to me:

> all(NA, FALSE)
> # [1] FALSE
> NA * FALSE
> # [1] NA

> I agree with all(NA, FALSE) being FALSE because we know for sure that all
> cannot be true. The same can be said of the multiplication -- whether NA
> represents TRUE or FALSE, the resulting value is 0 (FALSE).

> I also agree with the numeric case, FWIW: NA_real_ * 0 has to be NA_real_,
> because NA_real_ could be Inf or NaN, for both of which multiplication by 0
> gives NaN, hence 0 * NA_real_ is either 0 or NaN, hence it must be 
NA_real_.

I agree about almost everything you say above. ...
but possibly the main conclusion.

The problem with your proposed change would be that  integer
arithmetic gives a different result than the corresponding
"numeric" computation.
(I don't remember other such cases in R, at least as long as the
 integer arithmetic does not overflow.)

One principle to decided such problems in S and R has been that
the user should typically *not* have to know if their data is
stored in float/double or in integer, and the results should be the same
(possibly apart from staying integer for some operations).


{{Note that there are also situations were it's really
  undesirable that0 * NA   does *not* give 0 (but NA);
  notably in sparse matrix operations where you'd very often can
  now that NA was not Inf (or NaN) and you really would like to
  preserve sparseness ...}}


> [[alternative HTML version deleted]]

(as you did not use plain text ..)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Should 0L * NA_integer_ be 0L?

2020-05-23 Thread Michael Chirico

I don't see this specific case documented anywhere (I also tried to search
the r-devel archives, as well as I could); the only close reference
mentions NA & FALSE = FALSE, NA | TRUE = TRUE. And there's also this
snippet from R-lang:

In cases where the result of the operation would be the same for all
> possible values the NA could take, the operation may return this value.
>

This begs the question -- shouldn't 0L * NA_integer_ be 0L?

Because this is an integer operation, and according to this definition of
NA:

Missing values in the statistical sense, that is, variables whose value
> is not known, have the value @code{NA}
>

NA_integer_ should be an unknown integer value between -2^31+1 and 2^31-1.
Multiplying any of these values by 0 results in 0 -- that is, the result of
the operation would be 0 for all possible values the NA could take.

This came up from what seems like an inconsistency to me:

all(NA, FALSE)
# [1] FALSE
NA * FALSE
# [1] NA

I agree with all(NA, FALSE) being FALSE because we know for sure that all
cannot be true. The same can be said of the multiplication -- whether NA
represents TRUE or FALSE, the resulting value is 0 (FALSE).

I also agree with the numeric case, FWIW: NA_real_ * 0 has to be NA_real_,
because NA_real_ could be Inf or NaN, for both of which multiplication by 0
gives NaN, hence 0 * NA_real_ is either 0 or NaN, hence it must be NA_real_.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] base::order breaking change in R-devel

2020-05-23 Thread Jan Gorecki

Hi R developers,
There seems to be breaking change in base::order on Windows in
R-devel. Code below yields different results on R 4.0.0 and R-devel
(2020-05-22 r78545). I haven't found any info about that change in
NEWS. Was the change intentional?

Sys.setlocale("LC_CTYPE","C")
Sys.setlocale("LC_COLLATE","C")
x1 = "fa\xE7ile"
Encoding(x1) = "latin1"
x2 = iconv(x1, "latin1", "UTF-8")
base::order(c(x2,x1,x1,x2))
Encoding(x2) = "unknown"
base::order(c(x2,x1,x1,x2))

# R 4.0.0
base::order(c(x2,x1,x1,x2))
#[1] 1 4 2 3
Encoding(x2) = "unknown"
base::order(c(x2,x1,x1,x2))
#[1] 2 3 1 4

# R-devel
base::order(c(x2,x1,x1,x2))
#[1] 1 2 3 4
Encoding(x2) = "unknown"
base::order(c(x2,x1,x1,x2))
#[1] 1 4 2 3

Best Regards,
Jan Gorecki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

2020-05-23 Thread Hervé Pagès


On 5/22/20 18:12, brodie gaslam wrote:


FWIW what convinces me is consistency with other aggregating functions applied
to zero length inputs:

sum(numeric(0))
## [1] 0


Right.

And 1 is the identity element of multiplication:

> prod(numeric(0))
[1] 1

And the empty string is the identity element of string aggregation by 
concatenation.


H.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] GCC warning

2020-05-23 Thread Prof Brian Ripley


On 23/05/2020 07:38, Simon Urbanek wrote:

Adrian,

newer compilers are better at finding bugs - you may want to read the full 
trace of the error, it tells you that you likely have a memory overflow when 
using strncpy() in your package. You should check whether it is right. 
Unfortunately we can’t help you more specifically, because I don't see any link 
to what you submitted so can’t look at the code involved.


NB: debian-gcc on CRAN does have the latest version of gcc (10.1) and 
the link would likely have given fuller details (such links are provided 
on CRAN report pages but I do not know for submissions).


gcc does sometimes give false alarms here (there is one for R with gcc 
>= 9 and another for gcc >= 10) but see 
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ 
.  Most can easily be workaround by cleaner code.




Cheers,
Simon




On May 22, 2020, at 7:25 PM, Adrian Dușa  wrote:

I am trying to submit a package on CRAN, and everything passes ok on all platforms but 
Debian, where CRAN responds with an automatic "significant" warning:

* checking whether package ‘QCA’ can be installed ... [35s/35s] WARNING
Found the following significant warnings:
  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
‘__builtin_strncpy’ output may be truncated copying 12 bytes from a string of 
length 79 [-Wstringop-truncation]
See ‘/srv/hornik/tmp/CRAN/QCA.Rcheck/00install.out’ for details.


I know the cause of this: using a cursomized version of some external C library, 
coupled with  in the Description.

But I do not know hot to get past this warning, since it refers to a builtin 
GCC function strncpy. As far as I read, this should be solved by a simple GCC 
upgrade to the newest version, but that is something outside my code base, 
since GCC resides on the CRAN servers.

In the meantime, to get the package published, did anyone encountered a similar 
problem? If so, is there a workaround?

—
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] GCC warning

2020-05-23 Thread Simon Urbanek

Adrian,

newer compilers are better at finding bugs - you may want to read the full 
trace of the error, it tells you that you likely have a memory overflow when 
using strncpy() in your package. You should check whether it is right. 
Unfortunately we can’t help you more specifically, because I don't see any link 
to what you submitted so can’t look at the code involved.

Cheers,
Simon



> On May 22, 2020, at 7:25 PM, Adrian Dușa  wrote:
> 
> I am trying to submit a package on CRAN, and everything passes ok on all 
> platforms but Debian, where CRAN responds with an automatic "significant" 
> warning:
> 
> * checking whether package ‘QCA’ can be installed ... [35s/35s] WARNING
> Found the following significant warnings:
>  /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
> ‘__builtin_strncpy’ output may be truncated copying 12 bytes from a string of 
> length 79 [-Wstringop-truncation]
> See ‘/srv/hornik/tmp/CRAN/QCA.Rcheck/00install.out’ for details.
> 
> 
> I know the cause of this: using a cursomized version of some external C 
> library, coupled with  in the Description.
> 
> But I do not know hot to get past this warning, since it refers to a builtin 
> GCC function strncpy. As far as I read, this should be solved by a simple GCC 
> upgrade to the newest version, but that is something outside my code base, 
> since GCC resides on the CRAN servers.
> 
> In the meantime, to get the package published, did anyone encountered a 
> similar problem? If so, is there a workaround?
> 
> —
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
> https://adriandusa.eu
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

Re: [Rd] Surpising behavior when using an active binding as loop index in R 4.0.0

[Rd] writeBin and short writes

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

Re: [Rd] dbinom link

Re: [Rd] dbinom link

Re: [Rd] ftable <-> data.frame etc {was "justify hard coded in format.ftable"}

Re: [Rd] round() and signif() do not check argument names when a single argument is given

Re: [Rd] GCC warning

Re: [Rd] R-devel's ...names() questions

Re: [Rd] Compatibility issues caused by new simplify argument in apply function

Re: [Rd] Surpising behavior when using an active binding as loop index in R 4.0.0

Re: [Rd] Should 0L * NA_integer_ be 0L?

[Rd] Surpising behavior when using an active binding as loop index in R 4.0.0

Re: [Rd] Should 0L * NA_integer_ be 0L?

[Rd] Should 0L * NA_integer_ be 0L?

[Rd] base::order breaking change in R-devel

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

Re: [Rd] GCC warning

Re: [Rd] GCC warning

21 matches

Site Navigation

Mail list logo

Footer information