similar to: Should as.complex(NaN) -> NA?

>>>>> Michael Chirico >>>>> on Sun, 5 Nov 2023 09:41:42 -0800 writes: > This is another follow-up to the thread from September > "Recent changes to as.complex(NA_real_)". > A test in data.table was broken by the changes for NA > coercion to complex; the breakage essentially comes from > c(NA, 0+1i) > # vs

Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) should be, but rather, how I should read code like c(x, y) generally. Till now, I have thought of it like 'c(x, y)' is c(as(x, typeof(y)), y)` when "type(y) > type(x)". Basically in my mind, "coercion" in R <-> as.<newtype>(.) (or coerceVector() in C). So I tracked down the source

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

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

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

This is another follow-up to the thread from September "Recent changes to as.complex(NA_real_)". A test in data.table was broken by the changes for NA coercion to complex; the breakage essentially comes from c(NA, 0+1i) # vs c(as.complex(NA), 0+1i) The former is the output we tested against; the latter is essentially (via coerceVector() in C) what's generated by our

Hmm, it is not actually at odds with help(c), it is just that the autocoercion works different that it used to, so that as.complex(NA) == as.complex(NA_real) == NA_real_+0i) which now differs from NA_complex although both print as NA. I haven't been quite alert when this change was discussed, but it does look a bit unfortunate that usage patterns like c(NA, 0+1i) does not give complex NA

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

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,

Hi All, I have some data where I am doing fairly simple calculations, nothing more than adding, subtracting, multiplying and dividing. I’m running into a problem when I divide one variable by another and when they’re both 0 I get NaN. I realize that if you divide a non-zero by 0 then you get Inf, which is, of course, correct. But in my case I never get Inf, just NaN because of the structure

Hello, I notice in main/arithmetic.c, that NA and NaN are encoded differently(since every numeric NA comes from R_NaReal which is defined via ValueOfNA) . What is the benefit of treating these two differently? Why can't NA be a synonym for NaN? Thank you Saptarshi (R-2.9)

The help page for function identical says: 'identical' sees 'NaN' as different from 'as.double(NA)', but all 'NaN's are equal (and all 'NA' of the same type are equal). However, we have x <- NaN y <- as.double(NA) x # [1] NaN y # [1] NA identical(x,y) # [1] TRUE In my opinion, NaN and as.double(NA) should be distinguished as the

Hello, What is the best way to turn a matrix into a list removing NaN's? I'm new to R... Start: > mt = matrix(c(1,4,NaN,5,3,6),2,3) > mt [,1] [,2] [,3] [1,] 1 NaN 3 [2,] 4 5 6 Desired result: > lst [[1]] [1] 1 3 [[2]] [1] 4 5 6 Thanks! Ben [[alternative HTML version deleted]]

Thank you for the introduction to these recent changes, Martin. I think this was the second time I ran "make check" on that platform (Raspberry Pi 32-bit), and the first time (some months ago) it worked fine. So, that makes it kind of "suddenly", although I must say that my use of "make check" is very irregular. I compared code before and after the split you are

As a side note, Splus makes sin(x) NA, with a warning, for abs(x)>1.6*2^48 (about 4.51e+14) because more than half the digits are incorrect in sin(x) for such x. E.g., in R we get: > options(digits=16) > library(Rmpfr) > sin(4.6e14) [1] -0.792253849684354 > sin(mpfr(4.6e14, precBits=500)) 1 'mpfr' number of precision 500 bits [1]

Full_Name: Bill Simpson Version: 0.64.1 OS: linux Submission from: (NULL) (193.62.250.209) Here is the data file: x y z 1 1 1 1 2 2 2 1 NaN 2 2 4 >data<-read.table("~/junk.dat",header=TRUE) > data x y z 1 1 1 1 2 1 2 2 3 2 1 NaN 4 2 2 4 > matrix(data$z,length(y),length(x)) [,1] [,2] [1,] 1 4 [2,] 2 3 This is not the correct matrix. It seems

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:

How can I remove columns with NaN entries ? Here is my simple example: > data <- read.csv("test.csv") > xdata <- data[3:length(data)] > xs <- lapply(xdata, function(x){(x - mean(x))/sqrt(var(x))}) > x <- data.frame(xs) > x C D E F 1 -0.7071068 NaN -0.7071068 -0.7071068 2 0.7071068 NaN 0.7071068 0.7071068

On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when adding NA and NaN: > NA_real_ + NaN [1] NaN > NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for