On 2 August 2012 16:40, Alois Schloegl <alois.schlo...@ist.ac.at> wrote: > 1) I've never stated that this core functions are "buggy" - Never. > However, I'm saying that there is a better way to deal with NaN's > that what these "core functions" do.
You didn't use that word, but you implied it. You obviously think that propagating NaNs by default is an inferior method: On 15 February 2012 05:08, Alois Schloegl <alois.schlo...@ist.ac.at> wrote: > If you are tired of these nagging warnings, ask the developers of octave > to fix it. And I do not mean turning off the warning on shadowing > functions, but to implement the NaN-skipping behavior within the > existing core functions. You can only "fix" what is "buggy" (or erroneous). > 2) The idea of the NaN-toolbox is not that "NaNs should never be propagated > in a calculation" but that NaN's should be ignored in *statistical" analysis > (emphasis on "statistical"). Why is sumsq a "statistical" function, then? Potentially every function is statistical. The problem is that these two languages (Octave and Matlab) doesn't have namespaces to speak of. When we have offered ways to partition the namespace (e.g. classes) you refuse to use them. Introducing new functionality by abusing the namespace is problematic. Since we can't agree what to do, the warnings should remain. - Jordi G. H. ------------------------------------------------------------------------------ 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
