-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jaroslav Hajek wrote: > On Thu, Mar 5, 2009 at 4:04 PM, Alois Schlögl <alois.schlo...@tugraz.at> > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jaroslav Hajek wrote: >>> On Thu, Mar 5, 2009 at 12:02 PM, Alois Schlögl <alois.schlo...@tugraz.at> >>> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Jaroslav Hajek wrote: >>>>>> sumskipnan counts also the number of non-NaNs. >>>>>> [s,c]=sumskipnan(...) >>>>>> >>>>>> computing both s and c in a single step is beneficial for estimating >>>>>> mean, variance and other statistics. >>>>>> >>>>> well, you can do >>>>> >>>>> nans = isnan (x); >>>>> x(nans) = 0; >>>>> s = sum (x, dim); >>>>> c = size (x, dim) - sum (nans); >>>>> >>>>> Not exactly as fast as doing it all in a single loop, but simplistic. >>>> I guess, you meant >>>> c = size (x, dim) - sum (nans,dim); >>>> >>>> In terms of simplicity, >>>> [s,c]=sumskipnan(x,dim); >>>> will win. >>>> >>> Depends on what you count in. I wrote the first from top of my head, >>> whereas for the second I'd need to look up the syntax. But I don't >>> have any fundamental objections against the existence of sumskipnan, >>> of course. >> Fine. >> >>>>>>> Besides, I think the fact that the NaN package shadows Octave's >>>>>>> built-in functions is very dangerous and confusing, even though I >>>>>>> understand the motivation. I think this package should not be >>>>>>> installed by default. >>>>>> Where do you see a danger ? Please explain. >>>>>> >>>>> It seems that sometimes users (especially windows users) get this >>>>> package unknowingly loaded. Not that this is your fault, just that it >>>>> probably shouldn't be on by default in distributions. >>>>> >>>>> The more painful issue is that it makes the package less attractive to >>>>> use - for instance, if I want to use the nanmean function to get >>>>> nan-free mean, but I *don't* want the built-in mean to be shadowed >>>>> (because the replacement is slower). >>>> Therefore, it would be nice to have a pre-compiled sumskipnan that >>>> limits the performance hit. And their is certainly room for further >>>> improvement. >>> I don't want to limit it. I just don't want it to be there. I would >>> like to be able to use *both* nanmean and the default mean at the same >>> time. >> >> And there are many others, like me for example, that do not want to >> think about, whether nanmean or mean is the proper function for a >> specific problem. >> >> In case there are no NaN's, both yield the same result. >> In the presence of NaN's, the default mean results in NaN, while a >> perfectly valid result could be obtained. >> >> Or can You think of any reasonable problem, when mean should propagate >> the NaN's ? I can not. Consequently, there is no need to have both >> nanmean and mean. >> > > Just like Soren said, in most cases where NaN does not represent a > missing value.
It statistics nobody is asking what the meaning of the NaN is. Ignoring NaN is just the right thing to do. Again, I'm just talking about statistical functions, and do not generalize this to other areas. Alois -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmwzBUACgkQzSlbmAlvEIgalgCgiEdmzxx8tkuke/eO6JsFca2I H8MAoMNepLqJo9ps9r82hYvZxHRcuE34 =fV1+ -----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 Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
