similar to: complex NA's match(), etc: not back-compatible change proposal

On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called. > factor(c(complex(real=NaN), complex(imaginary=NaN))) [1] NaN+0i <NA> Levels: NaN+0i Look at <NA> in the result above. Yes, it happens in earlier versions of R, too. On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.

That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind. On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,

With 'z' of length 8 below, or of length 12 previously, one may try sapply(rev(z), match, table = rev(z)) match(rev(z), rev(z)) I found that the two results were different in R devel r70604. A shorter one: > z <- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) > sapply(z, match, table = z) [1] 1 1 2 > match(z, z) [1] 1 1 3 An explanation of the behavior: With normal

This is an RFC / announcement related to the 2nd part of PR#16885 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16885 about complex NA's. The (somewhat rare) incompatibility in R's 3.3.0 match() behavior for the case of complex numbers with NA & NaN's {which has been fixed for R 3.3.0 patched in the mean time} triggered some more comprehensive "research". I

Removal of ans[nas] <- NA from the code of function 'ifelse' in R is not committed (yet). Why? -------------------------------------------- On Mon, 28/11/16, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ? Cc: R-devel at r-project.org, maechler at stat.math.ethz.ch Date: Monday, 28 November, 2016, 10:00

I stand corrected. The part "If set to 'NULL', it implies 'useNA="always"'." is even in the documentation in R 2.8.0. It was my fault not to check carefully. I wonder, why "always" was chosen for 'useNA' for exclude = NULL. Why exclude = NULL is so special? What about another 'exclude' of length zero, like character(0) (not c(),

useNA <- if (missing(useNA) && !missing(exclude) && !(NA %in% exclude)) "ifany" An example where it change 'table' result for non-factor input, from https://stat.ethz.ch/pipermail/r-help/2005-April/069053.html : x <- c(1,2,3,3,NA) table(as.integer(x), exclude=NaN) I bring the example up, in case that the change in result is not intended.

By "an argument named 'use.names' is included for concatenation", I meant something like this, that someone might try. > c(as.Date("2016-01-01"), use.names=FALSE) use.names "2016-01-01" "1970-01-01" See, 'use.names' is in the output. That's precisely because 'c.Date' doesn't have 'use.names', so

Here is a patch to function 'stopifnot' that adds 'evaluated' argument and makes 'exprs' argument in 'stopifnot' like 'exprs' argument in 'withAutoprint'. --- stop.R 2019-05-30 14:01:15.282197286 +0000 +++ stop_new.R 2019-05-30 14:01:51.372187466 +0000 @@ -31,7 +31,7 @@ .Internal(stop(call., .makeMessage(..., domain = domain))) }

I found this part in the documentation of 'factor'. 'factor(x, exclude=NULL)' applied to a factor is a no-operation unless there are unused levels: in that case, a factor with the reduced level set is returned. If 'exclude' is used it should also be a factor with the same level set as 'x' or a set of codes for the levels to be excluded.

This is an example from https://stat.ethz.ch/pipermail/r-help/2007-May/132573.html . With R 2.7.2: > a <- c(1, 1, 2, 2, NA, 3); b <- c(2, 1, 1, 1, 1, 1) > table(a, b, exclude = NULL) b a 1 2 1 1 1 2 2 0 3 1 0 <NA> 1 0 With R 3.3.1: > a <- c(1, 1, 2, 2, NA, 3); b <- c(2, 1, 1, 1, 1, 1) > table(a, b, exclude = NULL) b a 1 2

>From an example in http://www.uni-muenster.de/ZIV.BennoSueselbeck/s-html/helpfiles/nargs.html , number of arguments in '...' can be obtained by (function(...)nargs())(...) . I now realize that sys.call() doesn't expand '...' when the function is called with '...'. It just returns the call as is. If 'stopifnot' uses sys.call() instead of match.call() , the

Yes, they work now. I mentioned them partly because the commit description said overflow for large n and partly to be considered for regression tests. -------------------------------------------- On Sat, 19/8/17, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] Issues of R_pretty in src/appl/pretty.c Cc: r-devel at r-project.org Date: Saturday, 19 August, 2017,

Examples similar to pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) with smaller 'n': pretty(c(-1,1)*1e304, n = 1e5, min.n = 1) pretty(c(-1,1)*1e306, n = 1e3, min.n = 1) A report on 'pretty' when working with integers, similar to what led to change of 'seq' fuzz, is https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15137 -------------------------------------------- On Tue,

------------------ >>>>> Henric Winell <[hidden email]> >>>>> on Wed, 21 Oct 2015 13:43:02 +0200 writes: > Den 2015-10-21 kl. 07:24, skrev Suharto Anggono Suharto Anggono via R-devel: >> Marius Hofert-4------------------------------ >>> Den 2015-10-09 kl. 12:14, skrev Martin Maechler: >>> I think so: the code above

See https://stat.ethz.ch/pipermail/r-devel/2017-August/074746.html for the origin of the example here. That pretty(c(-1,1)*1e300, n = 1e9, min.n = 1) gave 20 intervals, far from 1e9, but pretty(c(-1,1)*1e300, n = 1e6, min.n = 1) gave 1000000 intervals (on a machine), made me trace through the code to function 'R_pretty' in https://svn.r-project.org/R/trunk/src/appl/pretty.c . *lo is

Marius Hofert-4------------------------------ > Den 2015-10-09 kl. 12:14, skrev Martin Maechler: > I think so: the code above doesn't seem to do the right thing. Consider > the following example: > > > x <- c(1, 1, 2, 3) > > rank2(x, ties.method = "last") > [1] 1 2 4 3 > > That doesn't look right to me -- I had expected > > >

Another possible shortcut definition: assert <- function(exprs) do.call("stopifnot", list(exprs = substitute(exprs), local = parent.frame())) After thinking again, I propose to use ??? ? ? stop(simpleError(msg, call = if(p <- sys.parent()) sys.call(p))) - It seems that the call is the call of the frame where stopifnot(...) is evaluated. Because that is the correct context, I

On 'aggregate data.frame', the URL should be https://stat.ethz.ch/pipermail/r-help/2016-May/438631.html . vector(typeof(ans)) (or vector(storage.mode(ans))) has length zero and can be used to initialize array. Instead of if(missing(default)) , if(identical(default, NA)) could be used. The documentation could then say, for example: "If default = NA (the default), NA of appropriate

I am trying once again. By just changing f <- match(xlevs[f], nlevs) to f <- match(xlevs, nlevs)[f] , function 'factor' in R devel could be made more consistent and back-compatible. Why not picking it? -------------------------------------------- On Sat, 25/11/17, Suharto Anggono Suharto Anggono <suharto_anggono at yahoo.com> wrote: Subject: Re: [Rd] Function