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

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

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

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

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

> complex(real = 0, imaginary = Inf) [1] 0+Infi > Inf*1i [1] NaN+Infi >> complex(real = 0, imaginary = Inf)/5 [1] NaN+Infi See the Note in ?complex for the explanation, I think. Duncan can correct if I'm wrong. -- Bert On Thu, Sep 5, 2024 at 3:20?PM Leo Mada <leo.mada at syonic.eu> wrote: > Dear Bert, > > These behave like real divisions/multiplications: >

I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 + infinity i)/5 = (0 + infinity i). Here's what I get in C: (0,1) = (0, 1) atan((0,1)) = (0, inf) atan((0,1))/5 = (0, inf) Note the difference between I*infinity = (0,1)*infinity = (0*infinity,1*infinity) = (NaN,infinity) and (0,infinity)/5 = (0/5,infinity/5) = (0,infinity). The former involves multiplying 0 by infinity, which

Dear Bert, These behave like real divisions/multiplications: complex(re=Inf, im = Inf) * 5 # Inf+Infi complex(re=-Inf, im = Inf) * 5 # -Inf+Infi The real division / multiplication should be faster and also is well behaved. I was expecting R to do the real division/multiplication on a complex number. Which R actually does for these very particular cases; but not when only Im(x) is Inf.

Perhaps > Inf*1i [1] NaN+Infi clarifies why it is *not* a bug. (Boy, did that jog some long dusty math memories :-) ) -- Bert On Thu, Sep 5, 2024 at 2:48?PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > > Dear R Users, > > > > Is this desired behaviour? > > I presume it's a bug. > >

atan(1i) -> 0 + Inf i complex(1/5) -> 0.2 + 0i atan(1i) -> (0 + Inf i) * (0.2 + 0i) -> 0*0.2 + 0*0i + Inf i * 0.2 + Inf i * 0i infinity times zero is undefined -> 0 + 0i + Inf i + NaN * i^2 -> 0 + 0i + Inf i - NaN -> NaN + Inf i I am not sure how complex arithmetic could arrive at another answer. I advise against messing with infinities... use atan2() if you don't

On 2024-09-05 4:23 p.m., Leo Mada via R-help wrote: > Dear R Users, > > Is this desired behaviour? > I presume it's a bug. > > atan(1i) > # 0+Infi > > tan(atan(1i)) > # 0+1i > > atan(1i) / 5 > # NaN+Infi There's no need to involve atan() and tan() in this: > (0+Inf*1i)/5 [1] NaN+Infi Why do you think this is a bug? Duncan Murdoch

On 2024-09-06 12:44 a.m., Richard O'Keefe wrote: > I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 + > infinity i)/5 = (0 + infinity i). > Here's what I get in C: > (0,1) = (0, 1) > atan((0,1)) = (0, inf) > atan((0,1))/5 = (0, inf) > > Note the difference between I*infinity = (0,1)*infinity = > (0*infinity,1*infinity) = (NaN,infinity) > and

Dear R Users, Is this desired behaviour? I presume it's a bug. atan(1i) # 0+Infi tan(atan(1i)) # 0+1i atan(1i) / 5 # NaN+Infi There were some changes in handling of complex numbers. But it looks like a bug. Sincerely, Leonard [[alternative HTML version deleted]]

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