search for: na_complex_

In R 2.8.0 on Windows (tested both under ESS and under R Console in case there was an I/O issue) There is a bug in printing val <- matrix(list(NA_complex_,NA_complex_),1). > dput(val) structure(list(NA_complex_, NA_complex_), .Dim = 1:2) > print(val) [,1] [1,] [,2] [1,] Note that a large number of spaces are printed instead of NA. Compare the unproblematic real case: print(structure(list(NA_real_, NA_real_), .Dim = 1:2)) [,1] [,...

Hi all, Surprisingly (at least to me), `as.complex(NA_real_)` results in `complex(real = NA_real_, imaginary = 0)` rather than `NA_complex_`. It seems to me that this goes against the docs of `as.complex()`, which say this in the Details section: "Up to R versions 3.2.x, all forms of NA and NaN were coerced to a complex NA, i.e., the NA_complex_ constant, for which both the real and imaginary parts are NA. Since R 3.3.0, typical...

So, to summarize, the open questions are: (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) instead of NA_complex_? (2) Should the first argument in c(NA, x) and c(NA_integer_, x), where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0) instead of NA_complex_? My opinions: (1) No. The imaginary part of the result of parsing the strings "<b>i&quo...

>>>>> Mikael Jagan >>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x), > where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0) > instead of NA_complex_? > My opinions: > (1) No. The imaginary part of the result of parsing the strings &qu...

...(via > coerceVector() in C) what's generated by our data.table::shift() > However, these are now (r85472) different: > Im(c(NA, 0+1i)) > # [1] NA 1 > Im(c(as.complex(NA), 0+1i)) > # [1] 0 1 > The former matches the behavior of directly using NA_complex_: > Im(c(NA_complex_, 0+1i)) > # [1] NA 1 > On R4.3.2, they both match the NA_complex_ behavior: > Im(c(NA, 0+1i)) > # [1] NA 1 > Im(c(as.complex(NA), 0+1i)) > # [1] NA 1 > Is this intended behavior, does something need to be updated for c...

...rmer is the output we tested against; the latter is essentially (via coerceVector() in C) what's generated by our data.table::shift() However, these are now (r85472) different: Im(c(NA, 0+1i)) # [1] NA 1 Im(c(as.complex(NA), 0+1i)) # [1] 0 1 The former matches the behavior of directly using NA_complex_: Im(c(NA_complex_, 0+1i)) # [1] NA 1 On R4.3.2, they both match the NA_complex_ behavior: Im(c(NA, 0+1i)) # [1] NA 1 Im(c(as.complex(NA), 0+1i)) # [1] NA 1 Is this intended behavior, does something need to be updated for c() as well? Certainly it's messing with my understanding of how c()...

...at exactly c() is doing in this case: https://github.com/r-devel/r-svn/blob/71e7480b07767f3b7d5c45a4247959aa4d83d910/src/main/bind.c#L418-L425 And indeed! It's not "coercion" in the sense I just described... there's a branch for the 'x == NA_LOGICAL' case to _convert_ to NA_complex_. On Mon, Nov 6, 2023 at 3:08?AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > >>>>> Michael Chirico > >>>>> on Sun, 5 Nov 2023 09:41:42 -0800 writes: > > > This is another follow-up to the thread from September > > &q...

...s essentially (via > coerceVector() in C) what's generated by our data.table::shift() > > However, these are now (r85472) different: > > Im(c(NA, 0+1i)) > # [1] NA 1 > Im(c(as.complex(NA), 0+1i)) > # [1] 0 1 > > The former matches the behavior of directly using NA_complex_: > > Im(c(NA_complex_, 0+1i)) > # [1] NA 1 > > On R4.3.2, they both match the NA_complex_ behavior: > Im(c(NA, 0+1i)) > # [1] NA 1 > Im(c(as.complex(NA), 0+1i)) > # [1] NA 1 > > Is this intended behavior, does something need to be updated for c() as > well?...

This is fixed/changed in r-devel: > str(type.convert("i")) Factor w/ 1 level "i": 1 It was reported on July 18 as PR#16473, if you care. (Funny how an obscure issue goes unnoticed for a decade, then pops up twice independently within a few months. A property of the Poisson process, I suppose.) > On 07 Oct 2015, at 22:22 , William Dunlap <wdunlap at tibco.com>

I just noticed that read.table() and type.convert() interpret the string "i" as a missing value of type complex. > str(read.table(text=c("i\ni\ni\ni\n"))) 'data.frame': 4 obs. of 1 variable: $ V1: cplx NA NA NA ... > str(type.convert("i")) cplx NA If there are other strings in the column it makes the column character so most people

....complex(NaN), and its C equivalent, were changed to return complex(re=NaN,im=NaN) then the arithmetic examples would return NaN. Is there a better way for me to model how NaN's in complex numbers should work or is this a bug? While I was looking into this I noticed a bug in str(): > str(NA_complex_) Error in FUN(X[[1L]], ...) : subscript out of bounds Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com

Hi, I have discovered that sample() fails with an uninformative error message when the x argument is a single NA of type double or integer. I can reproduce the problem with the following code: base::sample(NA) # NA is of logical type above base::sample(NA_character_) base::sample(NA_complex_) base::sample(NA_real_) base::sample(NA_integer_) The last two lines throw the following error: Error in if (length(x) == 1L && is.numeric(x) && x >= 1) { : missing value where TRUE/FALSE needed My sessionInfo() : R version 3.3.1 (2016-06-21) Platform: x86_64-apple-darwin13...

According to http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Reserved-words if else repeat while function for in next break TRUE FALSE NULL Inf NaN NA NA_integer_ NA_real_ NA_complex_ NA_character_ ... ..1 ..2 etc. are all reserved keywords. However, in R 3.0.2 you can do things like: `if` <- function(cond, val1, val2) val2 after which if(TRUE) 1 else 2 returns 2. Similarly, users can change the implementation of `<-`, `(`, `{`, `||` and `&&`. Two que...

..._coef_cmplx", qr, y, PACKAGE = "base") : number of items to replace is not a multiple of replacement length If I change the section shown by context below from qr.coef as follows: if (is.complex(qr$qr)) { if (!is.complex(y)) y[] <- as.complex(y) coef <- matrix(NA_complex_, nrow = p, ncol = ny) #coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base") coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base")[1:p,] return(if (im) coef else c(coef)) } then i get goodness: my.qr.solve(cb...

...maintainer email addresses from package descriptions, so would often try mailing to incorrect addresses. ? debugger() could fail to read the environment of a call to a function with a ... argument. (Reported by Charlie Roosen.) ? prettyNum(c(1i, NA), drop0=TRUE) or str(NA_complex_) now work correctly. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com _______________________________________________ R-announce at r-project.org mailing...

...maintainer email addresses from package descriptions, so would often try mailing to incorrect addresses. ? debugger() could fail to read the environment of a call to a function with a ... argument. (Reported by Charlie Roosen.) ? prettyNum(c(1i, NA), drop0=TRUE) or str(NA_complex_) now work correctly. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com _______________________________________________ R-announce at r-project.org mailing...

..."warnings" as documented, now also in the case of no warnings where it previously returned NULL. * as.complex("1i") now returns 0 + 1i instead of NA with a warning. * z <- c(NA, 1i) now keeps the imaginary part Im(z[1]) == 0, no longer coercing to NA_complex_. Similarly, cumsum(z) correctly sums real and imaginary parts separately, i.e., without "crosstalk" in case of NAs. * On Alpine Linux iconv() now maps "latin2", "latin-2", "latin9" and "latin-9" to encoding names the OS knows...

..."warnings" as documented, now also in the case of no warnings where it previously returned NULL. * as.complex("1i") now returns 0 + 1i instead of NA with a warning. * z <- c(NA, 1i) now keeps the imaginary part Im(z[1]) == 0, no longer coercing to NA_complex_. Similarly, cumsum(z) correctly sums real and imaginary parts separately, i.e., without "crosstalk" in case of NAs. * On Alpine Linux iconv() now maps "latin2", "latin-2", "latin9" and "latin-9" to encoding names the OS knows...

...r defaults for the 'control' argument. o detach() now takes another argument, unload, which indicates whether or not to unload the package and then only cleans up the S4 methods if the package successfully unloads. o There are new constants NA_integer_, NA_real_, NA_complex_ and NA_character_ to denote NAs of those types, and they will be used in deparsing in place of as.integer(NA) etc unless .deparseOpts() includes "S_compatible". o dev.print() now recognizes 'screen devices' as all those with an enabled display list, rather than a hard-cod...

...r defaults for the 'control' argument. o detach() now takes another argument, unload, which indicates whether or not to unload the package and then only cleans up the S4 methods if the package successfully unloads. o There are new constants NA_integer_, NA_real_, NA_complex_ and NA_character_ to denote NAs of those types, and they will be used in deparsing in place of as.integer(NA) etc unless .deparseOpts() includes "S_compatible". o dev.print() now recognizes 'screen devices' as all those with an enabled display list, rather than a hard-cod...