[Rcpp-devel] inconsistent is_na() vs. is.na()

[Thomas Tse]

For whatever reason R chose NaN to be a subset of NA_real_, so I think it's better for Rcpp (which aims to provide C++ functionality in R) to follow the convention of R ...

from the following tests in R we see that for most R function (especially those with na.rm argument), NaN and NA are actually treated in the same way:

> x1 <- c(NaN, NA, 1.1, 2.2)

> x2 <- c(NA, NA, 1.1, 2.2)
> mean(x1)
[1] NA
> mean(x2)
[1] NA
> mean(x1, na.rm=TRUE)
[1] 1.65
> mean(x2, na.rm=TRUE)
[1] 1.65
> is.na(x1)
[1]  TRUE  TRUE FALSE FALSE
> is.na(x2)
[1]  TRUE  TRUE FALSE FALSE

of coz, there're some subtle differences (priority) in doing calculations on them:


> NaN + 1

[1] NaN
> NA + 1
[1] NA
> NA * Inf
[1] NA
> NaN * Inf
[1] NaN
> NaN * NA
[1] NA

Thomas,

On 2 October 2013 at 19:31, Thomas Tse wrote:
| is_na() does not handles R's NaN correctly, for the below test.cpp:
[...]
| is it possible to apply this change in next release of Rcpp ?

Certainly.  Though Romain has a point:

On 2 October 2013 at 13:36, Romain Francois wrote:
| The question is that do we want to be consistent with R or do we want
| something that makes sense.
|
| I believe that is_na should test if its argument is NA, and is_nan
| should check if is NaN

We have to make sure that we're doing is "consistent" for various definitions
of consistent. IEEE754 only knows NaN and Inf; NA is an R extension.

But from the top of my head I'd have to say I would want Rcpp to behave like
R over behaving like C++.  But I could be swayed.  Other views?

Dirk

--
Dirk Eddelbuettel | edd at debian.org| http://dirk.eddelbuettel.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131002/92b85b98/attachment-0001.html>