R devel - Nov 2023 - c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

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

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 at
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 at 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 at cbs.dk  Priv: PDalgd at gmail.com

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

I think you have confused yourself, and everything behaves as expected:

As we now have (in R-devel, since {r85233 | maechler | 2023-09-29 })

  ? ?as.complex(x)? now returns ?complex(real=x, imaginary=0)?
    for _all_ numerical and logical ?x?, notably also for ?NA?
    or ?NA_integer_?.

==> as.complex(NA) is indeed  complex(real = NA, imaginary = 0)

And now, in your

   c(as.complex(NA), 0+1i)

you are calling c() on two complex numbers, i.e., there is *no* coercion
(and c(.) is rather "trivial"),  and the same is true for

   c(NA_complex_, 0+1i)


However, in 85233, I had only modified & added examples to  ?as.complex, 
and now have added more (corresponding to the above NEWS entry);
-> svn rev 85475

.............

The underlying "dilemma" that nobody can help us with is that
"almost infinitely" many different complex numbers z fulfill
 is.na(z) |--> TRUE
and only one of them is  NA_complex_  and that may be unintuitive.

OTOH, we already have for the doubles that there are at least two
different x fulfulling is.na(x), namely  NaN and NA
and from C's point of view there are even considerably more
different NaN's .. but now I'm definitely digressing.
 
Martin