[Octave-bug-tracker] [bug #57814] [octave forge] (NaN) "shadows core function" warnings when loading package

[Alois Schlögl]

Follow-up Comment #4, bug #57814 (project octave):

As the maintainer of the NaN-package, I want to reply to these two comments;

[comment #1 comment #1:]
> I think that is the expected behavior of the NaN package. The intent is to
provide replacements of core functions that have different behavior under the
presence of NaN values.

and 

https://octave.discourse.group/t/so-many-warnings-upon-loading-nan-package/400

> For some reason the package maintainer did not choose to fix a reported bug
about this issue. (this comment links to this bug #57814)


Here is my response to these two comments: 

It is correct, that the intend of the NaN-toolbox is to modify the behaviour
of serveral statistical functions w.r.t. how NaNs are handled in these
functions. When the NaN-toolbox initially developed, installing these
functions did not cause warnings in Octave. Only at some later time, Octave
started to issue warnings. So these kind of warnings were caused by the
maintainers of Octave. And I must assume that this was done intentionally. 
 
IMO, the preferred solution would be that all statistical functions handle
NaN's gracefully, and just ignore NaNs. But I've received clear response that
such patches would not be accepted for the sake of "compatibility" to Matlab.
I'd say doing the "right thing" (i.e. skipping NaNs) trumps the argument of
some braindead "compatibility to Matlab". But the maintainers of Octave do not
agree. I guess that's the main dispute here. Other issues that were mentioned 
are:
- coding style (that these should be easily solvable)
- performance (this issue is mostly mute, because we are usually
memory-bandwith limited, not cpu-limited - in most cases there is no
performance penalty. 
- the corner case of mean - which might be also used in a non-statistical
context (when propagating NaNs is the right thing to do, e.g. computing the
center of a triangle). I'm not aware that any other statistical function could
be used in a meaningful way in a non-statistical context. And I'm sure we can
also find some solution for mean. 

What remains is the question whether "gracefully handling NaNs" or some
braindead "compatibility" issue is more important. I and the users of the
NaN-toolbox have already made up their mind on this - despite these scary
warnings.  

Addressing the issue of these (false) warnings can not be done from within the
NaN-toolbox alone, but there need to be an agreement on a wider basis. Only
then this issue is "solvable". 



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57814>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/