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 <michaelchiri...@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@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....@cbs.dk  Priv: pda...@gmail.com

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to