On Fri, Nov 16, 2012 at 2:25 AM, Romain Francois <rom...@r-enthusiasts.com> wrote: > Thanks for exploring these issue. This looks very useful. > > I get: > >> str( first_log(NA) ) > logi TRUE >> str( first_int(NA_integer_) ) > int NA >> str( first_num(NA_real_) ) > num NA >> str( first_char(NA_character_) ) > chr "NA" > > > For first_log: a bool can either be true or false. In R logical vectors are > represented as arrays of ints. When we coerce to bool, we test whether the > value is not 0. This works for most cases. I guess conversion to bool should > be avoided.
There's obviously no perfect solution, and that seems to be consistent with C++'s treatment of NAs in logical expression: evalCpp("NAN || FALSE") == TRUE > We have the is_na template function that can help: > >> evalCpp( 'traits::is_na<LGLSXP>( NA_LOGICAL )' ) > [1] TRUE >> evalCpp( 'traits::is_na<REALSXP>( NA_REAL )' ) > [1] TRUE > > And from this I can see we don't have is_na<STRSXP>, will fix this. > >> str( evalCpp( 'traits::get_na<REALSXP>()' ) ) > num NA >> str( evalCpp( 'traits::get_na<INTSXP>()' ) ) > int NA > > I guess we could come up with a nicer syntax for these, maybe static > functions in Vector<> so that we could do : > > IntegerVector::is_na( ) > NumericVector::get_na( ) Yes, that would be very nice. > >> str( evalCpp( 'std::numeric_limits<int>::min()' ) ) > int NA > > This is how NA_integer_ is represented. Thanks - the danger is that you might do something like: evalCpp( 'traits::get_na<INTSXP>() + 1' ) I'll make a note. > As said above, I'll add > > ...Vector::is_na > ...Vector::get_na > > to have something more consistent and not as cryptic as traits::is_na<...>( > ). People should not need to know what REALSXP, INTSXP, LGLSXP, ... mean. Great, thanks! Hadley -- RStudio / Rice University http://had.co.nz/ _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel