On Thu, Aug 2, 2012 at 4:27 PM, Alois Schloegl <alois.schlo...@ist.ac.at> wrote: > On 2012-08-02 22:43, Jordi Gutiérrez Hermoso wrote: >> >> On 2 August 2012 16:40, Alois Schloegl<alois.schlo...@ist.ac.at> wrote: >> >>> 3) after installing the NaN-toolbox, sum([1 NaN 2]) will still result in >>> NaN. But with the NaN-toolbox you have an additional function >>> sumskipnan([1,NaN,2]) which gives 3. >> >> >> Why don't you name all of your functions this way and not shadow core >> functions, then? For example, why do you overwrite sumsq? >> >> - Jordi G. H. > > > > Ok, sumsq() is a borderline case because you might argue that is not > necessarily a statistical function. > > But for the other functions, why should one need to thing about whether to > use var() or nanvar(), mean() or nanmean(), std() or nanstd() ? There is no > need for the NaN-propagating version, you always should use the nan-skipping > version.
This is not always true. For example, lets say I want to write a quick, simple test to see if rand is working. I might write something like assert (mean (rand (10000)(:)), .5, .1); # the mean value of rand should be around .5 I expect this case to fail if rand produces a NaN. > When one tries to solve a challenging problem, why should one need to thing > about whether to use var(), nanvar(), or some_other_varfunction() ? There is > just no need such proliferation of function names - all doing basically the > same. As far as the user is concerned, I agree with you. If a user installs the NaN package when they 'var' they want the nan skipping version. I do not think we should be spitting out a bunch of warnings as what the user wants is unambiguous. On the other hand, this creates an issue for scripts in core. Your functions are doing basically, but not quite the same thing. When writing scripts in core I expect NaNs to be propagated. It leads to a maintenance nightmare if you can not be sure of exactly how a function behaves (see gnulib/autotools). > Concerning you suggestion "to partition the namespaces (classes)". To me > this sounds like 2nd class citizens. But perhaps it's just me, and being not > familiar with this technique. In that case, it would be best if someone else > would transform the NaN-tb into a more compatible mode. I'm open for > suggestions. A more practical solution would be to use a package [1]. The main problem here is that Octave does not support packages (yet). What do you think about having NaN inside of a package? [1] http://www.mathworks.com/help/techdoc/matlab_oop/brfynt_-1.html > Alois Max Brister ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
