Re: package nan warnings

[Max Brister]

On Thu, Aug 2, 2012 at 4:27 PM, Alois Schloegl <address@hidden> wrote:
> 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.

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