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

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(comple

[Rd] Difference Linux / Windows

Hi the list, I am writing a package that happen to not be compatible with linux because I did not know that the function "savePlot" was available only on windows. Is there a list of "incompatible" function? How can I get this kind of information? Thanks Christophe

Re: [Rd] Difference Linux / Windows

On 3/31/10 1:12 PM, Christophe Genolini wrote: Hi the list, I am writing a package that happen to not be compatible with linux because I did not know that the function "savePlot" was available only on windows. Is there a list of "incompatible" function? How can I get this kind of information? O

[Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")

Hi, > class(as(1:4, "numeric")) [1] "integer" Surprising but an explanation could be that an integer vector being a particular case of numeric vector, this coercion has nothing to do because 1:4 is already numeric. And indeed: > is.numeric(1:4) [1] TRUE > is.numeric(as(1:4, "numeric")

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

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

Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")

The example is confusing and debatable, but not an obvious bug. And your presentation of it is the cause of much of the confusion (unintentionally I'm sure). First, slipping from the as() function to methods for the coerce() function might surprise a less experienced user. And in fact, that