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
Should as.complex(NaN) -> NA?
2 messages · William Dunlap, Charles C. Berry
On Wed, 31 Mar 2010, William Dunlap wrote:
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.
Just a guess here:
as.complex(sqrt(as.complex(-1)))
[1] 0+1i
as.complex(sqrt(-1))
[1] NA Warning message: In sqrt(-1) : NaNs produced It protects from assuming that the latter truly is not a number. Chuck
> 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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Charles C. Berry (858) 534-2098
Dept of Family/Preventive Medicine
E mailto:cberry at tajo.ucsd.edu UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901