[Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

[peter dalgaard]

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 for the 1st component, effectively changing the interpretation from "I don't know what this is" to "I don't know what this is but I'm sure it is on the real line".

Also, notice that things like 

> Im(scan(text= "NA 0+1i", what=complex()))
Read 2 items
[1] NA  1

and

> Im(as.complex(c(NA,"0+1i")))
[1] NA  1

but Martin probably thought more deeply about this?

-pd

> On 5 Nov 2023, at 18:41 , Michael Chirico <michaelchirico4 using gmail.com> wrote:
> 
> 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 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() behaves, e.g. in ?c
> 
>> All arguments are coerced to a common type which is the type of the
> returned value
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes using cbs.dk  Priv: PDalgd using gmail.com