Re: NA and NaN

[John W. Eaton]

On 12-Mar-2008, Søren Hauberg wrote:

| In what version do you see that isnan(NA) gives 'false'? I have never
| observed this behaviour, so I was quite surprised by your questions.

It was apparently this way in 2.1.

Octave's NA is implemented as a special NaN value with a bit pattern
identical to the NA value used by R specifically for compatibility
with R, so Octave and R should be able to share binary data files that
contain NA.

I think R used to have an isNaNorNA function, and my understanding way
back when was that isna should only return true for the special NaN
value that is NA, not others, isnan should only return true for other
NaN values, and there was a separate function that would return true
for both (isNaNorNA?).  But now I think R just uses isna and isnan,
and isnan returns true for any NaN value, including NA.  So Octave
should also work this way.  If that's not correct for the current
versions of Octave and R, then file a bug report.

| > However, in light of Søren's observation, would it preferable to use NA
| > instad of NaN for missing values?  What about octave-forge packages
| > "statistics" and "nan"?  What about Matlab compatibility?
| Matlab doesn't have NA, so compatibility can be an issue, depending on
| the situation. The interpolation code (eg. 'interp2') uses NA when it
| performs extrapolation. In matlab NaN is used. Here there are no
| compatibility issues. Personally, I always use NA, when I'm missing
| data, and I never really understood how NaN is a good indicator of the
| same.

As was recently reported, one problem with NA is that it might not be
properly preserved across calculations.  NA should work fine as a
marker, but if you do calculations with it, you may find that some
functions can return other NaN values when given NA as an argument.
It's not clear to me how to deal with that.  I don't think we want to
have to wrap every library function with a check for NA.

jwe