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...

It seems to me that the documentation of R's complex class & R's atan function do not tell us what to expect, so (as others have suggested), some additional notes are needed. I think that mathematically atan(1i) should be NA_complex_, but R seems not to use any mathematically standard compactification of the complex plane (and I'm not sure that IEEE does either). Incidentally, the signature of the complex constructor is confusing. complex(1L) returns zero, but complex(1L, argument=theta) is an element of the unit circle. T...

...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...