(Mis)use of the is_nan_or_na() mapper function

[John W. Eaton]

On 10-Oct-2004, Paul Laub <address@hidden> wrote:

| P.P.S. Having NA is a good idea but how is it implemented?
| How do you keep it separate from NaN and Inf and still use 
| IEEE style floating point math? I notice that sprintf("%f", NA)
| returns "NaN".

NA is a special NaN value.  The one chosen for Octave is precisely the
same one that GNU R uses for this purpose.  It is possible that an
operation that generates a NaN would produce the specific value
selected to represent NA, but it appears that this doesn't happen in
practice (it has worked well for R for some time now).

Now, should we eliminate the is_nan_or_na function entirely and have
only isnan and isna, and have "isnan (NA)" also return true
(currently, it does not)?  Then if you needed to know whether a value
was NA (only, and not some other type of NaN that resulted from a
calculation), you could check with isna, and if you needed to know
whether something was any type of NaN value, you could check with
isnan.  If you needed to know that something was a NaN, but not NA,
you would have to use a logical expression like "isnan(x) & (! isna(x))".

Comments?

jwe



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------