documentation for is.na and is.nan in DSL

[paciorek]

I don't think we document that is.na and is.nan are available in the DSL.

Also, is.na does not seem to function as one would expect:

a = nimbleFunction(
 run=function(x=double(0)) {
 if(is.na(x)) x <- 7
 returnType(double(0))
 return(x)
 })
ca=compileNimble(a)
 a(NA)
[1] 7
ca(NA)
[1] -2147483648

1. Would someone be willing to do this in an appropriate place in the manual before 0.6-6 to help me out?
2. @perry or a volunteer, would you look at how ISNA is handled in C++?

[perrydv]

This is a quick note to say that ca(as.numeric(NA)) works as expected. The problem evidently is that when SEXP_2_double (RcppUtils.cpp) detects that the input is logical (default storage.mode for NA) and casts it to double, it invalidates NA. I might be able to put in a PR later today or tomorrow to fix this systematically in various R-C interface functions, but in the moment I'm just noting what's happening.

[perry]

This is not the @perry you are looking for.

[danielturek]

Now that's pretty funny @perry @perrydv

[fritzo]

@paciorek I'll volunteer to look at how is.na is handled in C++...

[fritzo]

Yikes, looks like we've overloading an R function to get things to compile (nimDists.h line 10)

bool R_IsNA(NimArr<1, double> &P); // We use ISNA which is a macro for R_IsNA, so now to overload for the vector case, we muse overload R_IsNA

This is dangerous and likely to lead to trouble. I'd recommend replacing ISNA in our compiler with an overloaded nimIsNan that we own.

[paciorek]

I added info on is.na and is.nan to Table 10.1 of manual as of v 0.6-9.

Note that trying to set NAs in nf code also causes compilation problems, e.g.,

a = nimbleFunction(
    run=function() {
        x <- numeric(1, NA) # causes error
        y <- NA             # also causes error
        returnType(double(1))
        return(x)
    })
ca=compileNimble(a)