reduction funs optimizations + min/max question

[John W. Eaton]

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.
| 
| A short benchmark (set n to suitable value):
| n = 5e3;
| c = {1,single(1),1+1i,single(1+1i)};
| for i = 1:4
|   a = c{i}*rand (n);
|   disp (typeinfo (a));
|   tic; b = sum (a); toc
|   tic; b = sum (a, 2); toc
|   tic; b = prod (a); toc
|   tic; b = prod (a, 2); toc
|   tic; b = sumsq (a); toc
|   tic; b = sumsq (a, 2); toc
|   tic; b = cumsum (a); toc
|   tic; b = cumsum (a, 2); toc
|   tic; b = cumprod (a); toc
|   tic; b = cumprod (a, 2); toc
| endfor
| 
| on Core 2 @ 2.83 GHz, g++ -O3 -funroll-loops -march=native,
| I get with a recent tip:
| 
| the relative speed-ups, measured as (old_time / new_time - 1) * 100%
| 
|   431%
|  1009%
| [...]
| 
| 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