help-octave
[Top][All Lists]
Advanced

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

Re: handling NaN


From: Schloegl Alois
Subject: Re: handling NaN
Date: Tue, 13 Aug 2002 19:32:07 +0200 (MEST)
User-agent: IMP/PHP IMAP webmail program 2.2.8

Zitiere Paul Kienzle <address@hidden>:

> On Wed, Aug 07, 2002 at 11:28:54PM +0200, Schloegl Alois wrote:
> > 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
> (http://octave.sf.net),
> > > | 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.
> > 
> > <rant>
> > 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.
> > </rant>
> > 
> > If the octave-froge implementation of nanmax.m is too slow,
> > then we can always rewrite it as a *DLD function.
> > 
> > ----------------------------------------------------
> > 
> > 
> > Andy,
> > 
> > 
> > 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. 
> 
> The consequences are that MISSING VALUES should be omitted by default. 


Ok, you are right. Actually, I meant Missing Values. However, on explanation of
this lapsus is that in statistitics and stochastic signal processing, there is
no difference between NaNs and Missing values. 

> NaNs are
> not missing values in many (most) computations, but instead are things
> that inform you that your computation has gone awry.  

In my experience, NaN's can be omitted most of the time. 

Lets take the example of calculating the mean (or any other statistic) from a
data series x: 
Lets further assume, x is a ratio of s over u; i.e. x=s./u. 
It could happen that for some elements s and u are zero, resulting in x=0/0. 
Clearly, 0/0 is not defined and results in NaN (an awry computation?). But we
can still calculate the mean from that data series x. 
The bottomline is that it does not matter whether NaN's come from 0/0 or from
somewhere else. 


> If your code does not explicitly deal
> with these problems itself (e.g., by using nanfun) then the invalid
> value should
> be propogated back to somewhere that the user can see it.
> 

NaN's can be always checked explicitly with ISNAN - if there is a need for it.
Accordingly, there is no need for nanfun. 

 Alois 




-------------------------------------------------------------
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
-------------------------------------------------------------



reply via email to

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