[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(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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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? One way is to obtain a copy of the R sources and then grep the Rd files for '#ifdef'. I don't claim this is convenient. There has been discussion, and I believe general consensus, that we'd like to eliminate the conditional documentation. This requires editing the Rd files to make the contents sensible (you can't just remove the #ifdef's). Patches along these lines would be welcome. + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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"))
[1] TRUE
However, 'as(1:4, "numeric")' is inconsistent with
> class(as.numeric(1:4))
[1] "numeric"
And, even more confusing, if you look at the coerce,ANY,numeric
method:
> selectMethod("coerce", c("integer", "numeric"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.numeric(from)
if (strict)
attributes(value) <- NULL
value
}
Signatures:
from to
target "integer" "numeric"
defined "ANY" "numeric"
it calls as.numeric()!
So how can 'as(1:4, "numeric")' not return the same thing as
'as.numeric(1:4)' looks like a mystery to me. Could it be
conceivable that I found a bug?
Cheers,
H.
> sessionInfo()
R version 2.11.0 Under development (unstable) (2010-03-15 r51282)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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=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@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:cbe...@tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 is
the point here. If you look at the as() function, it jumps through
several hoops and in particular selects a method from coerce in such a
way as NOT to use inheritance on the from= argument. (I think this
makes sense in this case). So I would assert that your selectMethod()
output below came from a different session than the as(1:4, "numeric").
Starting from a clean session with R 2.10.1:
> class(as(1:4,"numeric"))
[1] "integer"
> selectMethod("coerce", c("integer","numeric"))
Method Definition:
function (from, to = "numeric", strict = TRUE)
if (strict) {
class(from) <- "numeric"
from
} else from
Signatures:
from to
target "integer" "numeric"
defined "integer" "numeric"
Note, no call to as.numeric(). In a session without a previous call to
as(), your selectMethod() call triggered a standard inherited method
selection. And if you had then gone on to as(), the result would have
been different.
In a different clean session:
> getMethod("coerce", c("integer", "numeric"))
Error in getMethod("coerce", c("integer", "numeric")) :
No method found for function "coerce" and signature integer, numeric
> selectMethod("coerce", c("integer", "numeric"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.numeric(from)
if (strict)
attributes(value) <- NULL
value
}
Signatures:
from to
target "integer" "numeric"
defined "ANY" "numeric"
> class(as(1:4,"numeric"))
[1] "numeric"
No argument about this being confusing. Perhaps one should prohibit
standard selectMethod() on coerce() but that seems a bit arcane to
thwart folks like you!
Suggested improvements for the current implementation are welcome, so
long as they consider the best definition of as() in the general sense.
Regards,
John
On 3/31/10 3:52 PM, Hervé Pagès wrote:
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"))
[1] TRUE
However, 'as(1:4, "numeric")' is inconsistent with
> class(as.numeric(1:4))
[1] "numeric"
And, even more confusing, if you look at the coerce,ANY,numeric
method:
> selectMethod("coerce", c("integer", "numeric"))
Method Definition:
function (from, to, strict = TRUE)
{
value <- as.numeric(from)
if (strict)
attributes(value) <- NULL
value
}
Signatures:
from to
target "integer" "numeric"
defined "ANY" "numeric"
it calls as.numeric()!
So how can 'as(1:4, "numeric")' not return the same thing as
'as.numeric(1:4)' looks like a mystery to me. Could it be
conceivable that I found a bug?
Cheers,
H.
> sessionInfo()
R version 2.11.0 Under development (unstable) (2010-03-15 r51282)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
