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

[Mikael Jagan]

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 result of parsing the strings "<b>i",
         "<a>+<b>i", and "<a>-<b>i" can be nonzero.
         Consider, e.g., Im(eval(str2lang("0+1i"))) and Im(as.complex("0+1i")).
         If NA_character_ means "a string with unknown content", then we should
         not assume that the string is parsed as a real number.

     (2) Yes.  I'd very much like to preserve the identity of c(Im(NA), Im(x))
         and Im(c(NA, x)) for atomic (excluding raw, character) vectors 'x'.

And while typing this response I noticed the following in current R-devel and
current R-patched:

     > 0+1i
     [1] 0+1i
     > 1i
     [1] 0+1i
     > as.complex("0+1i")
     [1] 0+1i
     > as.complex("1i")
     [1] NA
     Warning message:
     NAs introduced by coercion

That warning seems wrong to me ...

Mikael

On 2023-11-07 6:00 am, r-devel-request using r-project.org wrote:
>>>>>> Michael Chirico
>>>>>>      on Mon, 6 Nov 2023 23:18:40 -0800 writes:
>      > 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 (which admittedly has been this way for much
>      > longer than the present discussion) to see what exactly c() is doing in
>      > this case:
> 
>      >https://github.com/r-devel/r-svn/blob/71e7480b07767f3b7d5c45a4247959aa4d83d910/src/main/bind.c#L418-L425
> 
>      > And indeed! It's not "coercion" in the sense I just described... there's a
>      > branch for the 'x == NA_LOGICAL' case to_convert_  to NA_complex_.
> 
> Yes; "of course" ... still, I did not answer your main question,
> as you did ask +/-  if  c() should not get an adjustment to the
> new  as.complex(<numeric-alike>)  |-->  (Re = NA, Im = 0)
> behavior.
> 
> And that is still a valid open question. ... contrary to what I
> wrote yesterday; sorry for that "answering a different
> question".
> 
> Martin
> 
> 
>      > On Mon, Nov 6, 2023 at 3:08 AM Martin Maechler<maechler using stat.math.ethz.ch>
>      > wrote:
> 
>      >> >>>>> 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
>      >>