From wdunlap at tibco.com  Wed Mar 31 21:04:42 2010
From: wdunlap at tibco.com (William Dunlap)
Date: Wed, 31 Mar 2010 12:04:42 -0700
Subject: [Rd] Should as.complex(NaN) -> NA?
Message-ID: <77EB52C6DD32BA4D87471DCD70C8D70002B76B26@NA-PA-VBE03.na.tibco.com>

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 



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