From m|ch@e|ch|r|co4 @end|ng |rom gm@||@com  Sun Nov  5 18:41:42 2023
From: m|ch@e|ch|r|co4 @end|ng |rom gm@||@com (Michael Chirico)
Date: Sun, 5 Nov 2023 09:41:42 -0800
Subject: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
Message-ID: <CAPRVBcx4OxpWDH_cyunMfZ=eLhQCD3V62ka1yQV4y5jCoEXL6A@mail.gmail.com>

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



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