RE: reduction funs optimizations + min/max question

[Hall, Benjamin]

|-----Original Message-----
|From: John W. Eaton [mailto:address@hidden 
|Sent: Friday, February 13, 2009 3:33 PM
|To: Jaroslav Hajek
|Cc: octave maintainers mailing list
|Subject: reduction funs optimizations + min/max question
|
|On 13-Feb-2009, Jaroslav Hajek wrote:
|
|| this changeset: 
|http://hg.savannah.gnu.org/hgweb/octave/rev/53b4fdeacc2e
|| reimplements the reduction and cumulative reduction "cores" 
|sum, prod,
|| sumsq, cumsum and cumprod
|| for better performance.

<snip>

|| n-d arrays seem to yield even slightly better results.
|
|Thanks for looking at this.  These are impressive speedups.
|
|| I would like to also address min & max. I'm not, however, entirely
|| certain about the expected behaviour of min/max
|| w.r.t NaN and NA. Currently, the following holds:
|| max(NA, NaN) = max (NaN, NA) = NA
|| max([NA, NaN]) = NaN
|| max([NaN, NA]) = NA
|| 
|| so, it seems that the behaviour is pretty much arbitrary, i.e. NA is
|| not treated as "weaker" or "stringer" kind of NaN.
|| Matlab has no NA, so that's no source of authority here. So, is there
|| anything else to follow?
|
|Since NaN and NA are both NaNs, does it matter?  
|
|What does sort do?
|
|Octave's NA was patterned after NA in R, so what does R do?
|
|jwe
|

I'm no R expert (but I happened to be using it right now).  R seems to
mimick octave's current behavior.

> max(NaN,NA)
[1] NA
> max(NA,NaN)
[1] NA
> max( c(NA,NaN) )
[1] NaN
> max( c(NaN,NA) )
[1] NA
> 

Although, that is not what the documentation says:

By definition the min/max of any vector containing an NaN is NaN, except
that the min/max of any vector containing an NA is NA even if it also
contains an NaN. Note that max(NA, Inf) == NA even though the maximum
would be Inf whatever the missing value actually is. 

The R behavior is the same on my windows build (2.7.1) and linux build
(2.8.1) (both on the same architecture).  For me, NA, NA, NaN, NA
doesn't much matter.