Am 28.02.2012 um 23:42 schrieb Jordi Gutiérrez Hermoso: > Ping on the discussion below. I really would like to settle this once > and for all and stop this petty war we've been having about shadowing > core functions and then enabling warnings when core functions are > shadowed.
The question that remains for me is whether shadowing of core functions is really necessary for NaN-handling. Matlab has quite a few nan...-functions that ignore NaNs without shadowing any core funtions: http://www.mathworks.de/help/toolbox/stats/bq_w_hm.html#brjjdzm-1 > I think skipping NA instead of NaN would be desirable and a good agreement. At first glance I'd say yes, but won't we introduce a source for subtle bugs? We already have cumsum((1:10)')==tril(ones(10))*(1:10)' as well as cumsum((1:10)')==sparse(tril(ones(10)))*(1:10)' evaluating to all true, whereas cumsum([1:9,NA])'==tril(ones(10))*([1:9,NA])' evaluates to all false and cumsum([1:9,NA]')==sparse(tril(ones(10)))*([1:9,NA])' evaluates to one false. Would we be in danger of introducing a combinatorial explosion of varying semantics for what may be misjudged as equivalent expressions by new users or any other people ignorant of the existence of NaNs? For my own part I'd say NAs should be dealt with at a high level, and core functions should treat them just like any other NaN except that 'real' NaNs should take precedence when both occur in an expression. I'd thus vote for keeping Alois' library, but suggest that maybe some functions shadowing core functions be renamed if that seems viable. Later, Alex -- Dr. Alexander Klein, Diplom-Mathematiker Physiologisches Institut | TransMIT-Bereich Raum 543 | für Mathematische Analysen | und Feld-Simulationen Aulweg 129 | Heinrich-Buff-Ring 44 35392 Giessen | 35392 Giessen ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
