[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handling NaN

From: Schloegl Alois
Subject: Re: handling NaN
Date: Wed, 07 Aug 2002 23:28:54 +0200 (MEST)
User-agent: IMP/PHP IMAP webmail program 2.2.8

On Wed, 31 Jul 2002, John W. Eaton wrote:
> On 31-Jul-2002, Paul Kienzle <address@hidden> wrote:
> | Or you can use nanmax as defined in octave-forge (,
> | which does the same thing:
> I've also noticed that Matlab now removes NaN automatically in min and
> max (but apparently not yet in std, mean, etc.).  Although I would
> prefer to distinguish between missing and NaN, maybe Octave should
> ignore NaNs in min and max for compatibility?

I guess this is one of those "should octave do bug-for-bug compatibility?"
type questions.

My personal opinion is that min or max _should_ by default
retain NaN values. NaN normally means that something significant
happened. That significant event should be retained by default.
The choice to ignore NaN should be semantically explicit,
such as by using nanfunction.

If the octave-froge implementation of nanmax.m is too slow,
then we can always rewrite it as a *DLD function.



from the viewpoint of statistics and stochastic signal processing, I can not 
agree with your opinion.  

1) If NaN's are important, it can be always tested with ISNAN. 

2) There is also no reason to have two different functions doing basically the 
same (like FUN and NANFUN). Most of the time its more difficult to decide 
whether FUN or NANFUN is better, than an explicit check with ISNAN. 

3) The code is more readable if you use explicit check for NaN's rather than an 
implicit check (by using FUN or NANFUN)

The consequences are that NaN's should be omitted by default. 

This concept has been already implemented in
and can be also applied to stochastic signal processing

It works very, very well. Even I was surprised by the consequences; they went 
beyond my own expectations. E.g. Autoregressive estimation 
algorithms were suddenly able to handle "missing values".    

Finally, Octave would go beyond implementing bug-to-bug compatibility. In fact, 
this concept could bring Octave a step ahead. 


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

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]