-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jaroslav Hajek wrote: > On Fri, Mar 6, 2009 at 1:50 PM, Alois Schlögl <[email protected]> > wrote: > > Fair example. This example requires some explicit handling of NaN's. > Lets look at the case that raises an error: > > c = mean(x); > if any(isnan(c)) > error(); > end; > > > With the skippingNaN-mean() you do > > if any(isnan(x(:)) > error(); > end > c=mean(x); > > > In both cases you need somethink to do about the NaN's e.g. some error > handling. Except for the performance issue, there is no disadvantage in > using the nanskipping-mean(). > > >> No, I want just to leave them there.
I know, you are using NaN's as a marker that an error occured in some earlier processing steps, and you do not care where this has happened. However, at some point you need to do something about the result, and it will make a difference whether its a NaN or not. Because if this would not matter, there would be no need to keep the NaN. > > And one could also imagine to address the performance issue by a change > in the interface (e.g. by raising a global flag) > > [c,N]=mean(x); > if flag_nans_occured(), > error(); > end > > Actually, flag_nans_occured() is now supported. > > >> So you don't want to remember nanmean/mean but it's OK to remember >> checking for flag_nans_occured ()? In most cases, the check is not needed because nanskip-mean() is already doing the right thing. Only, in the rare cases where you need some explicit handling of NaN's, you can use this. > > --- > > You might consider it an advantage, that you can do the error checking > much later, e.g. > > c = mean(x); > d = do_some_more(c); > if any(isnan(d)) > error(); > end; > > However, this makes reading the code and finding the error more > difficult. Because, one can not easily see which step is causing the NaN. > >> If I'm just writing a function that calculates, say, the centroid and >> distance vectors to vertices, I just want to return NaNs, not gripe >> inside the function. This is how most of Octave's functions work. That >> lets the user to choose the most suitable error handling. Maybe this >> particular invalid result won't be actually used in the computation - >> that's the whole point of NaNs, they're just more flexible than >> runtime errors. using error() above was just an example. It should point out that NaN's will make a difference. Typically, one is using the NaN, perhaps you decide on the fact whether there is a nan, whether you are throwing away the result or not. But you are using the NaN at some later time. What you call "flexibility" comes at the cost that you do not know what was causing the NaN. Its a very crude approach of error handling. A numerical algorithm can always return NaN, and it would not be incorrect. The point is that with a crude NaN-propagation, you might reject cases, were a more sensible approach might work fine. Alois -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmxOQYACgkQzSlbmAlvEIgAKQCcD8kjYRI5bhZu8xZEZBzicABg NdAAnjDtjdSSa0T6cmVbXeOdI+WpqDqp =NELU -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
