# [Rd] Should as.complex(NaN) -> NA?

William Dunlap wdunlap at tibco.com
Wed Mar 31 21:04:42 CEST 2010

```I'm having trouble grokking complex NaN's.
This first set examples using complex(re=NaN,im=NaN)
give what I expect
> Re(complex(re=NaN, im=NaN))
[1] NaN
> Im(complex(re=NaN, im=NaN))
[1] NaN
> Arg(complex(re=NaN, im=NaN))
[1] NaN
> Mod(complex(re=NaN, im=NaN))
[1] NaN
> abs(complex(re=NaN, im=NaN))
[1] NaN
and so do the following
> Re(complex(re=1, im=NaN))
[1] 1
> Im(complex(re=1, im=NaN))
[1] NaN
> Re(complex(re=NaN, im=1))
[1] NaN
> Im(complex(re=NaN, im=1))
[1] 1
but I don't have a good mental model that explains
why the following produce NA instead of NaN.
> as.complex(NaN)
[1] NA
> Im(complex(modulus=NaN, argument=NaN))
[1] NA
> Re(complex(modulus=NaN, argument=NaN))
[1] NA
> Re(1i * NaN)
[1] NA
> Im(1i * NaN)
[1] NA
> Re(NaN + 1i)
[1] NA
> Im(NaN + 1i)
[1] NA

It may be that if as.complex(NaN), and its C equivalent,
were changed to return complex(re=NaN,im=NaN) then the
arithmetic examples would return NaN.  Is there a
better way for me to model how NaN's in complex numbers
should work or is this a bug?

While I was looking into this I noticed a bug in str():
> str(NA_complex_)
Error in FUN(X[[1L]], ...) : subscript out of bounds

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com

```