Re: package nan warnings

[Alois Schloegl]

On 2012-08-02 22:43, Jordi Gutiérrez Hermoso wrote:
> On 2 August 2012 16:40, Alois Schloegl<address@hidden>  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.

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.

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.


Alois




   Alois