From bug-octave-request at bevo dot che dot wisc dot edu  Sat Jul 29 02:20:19 2000
Subject: Ordered NaN on purpose?
From: Edward Jason Riedy <ejr at EECS dot Berkeley dot EDU>
To: bug-octave at bevo dot che dot wisc dot edu
Date: Sat, 29 Jul 2000 02:20:56 -0500 (CDT)


There's a bug in x{min,max} where NaN is treated as ordered.  The
isnan (x) test should be isnan (y).  However, there's also a good
deal of code in dMatrix.cc and CMatrix.cc that quite clearly 
states that this is intentional (without comment).

Why?  And would you accept a patch that fixes it?  (I thought I
could just use xmin to implement {row,col}_min trivially, but
that would require working backwards through the row/col, which
would imply that it couldn't stop early with -Inf.)

It's a bug because NaN is unordered.  5 < NaN and 5 > NaN are
both false (and raise the invalid operation flag, according to
IEEE), as are NaN < NaN and NaN > NaN.  I honestly don't see
how NaN could be the result of min or max on any set containing
real numbers.  Likewise, min([NaN, -Inf]) == NaN completely
baffles me.

Note: Matlab has min(NaN, 5) == 5, etc.  As does GNU libc and
gcc.  And [a, b] = min([NaN, NaN]) sets [a, b] == [NaN, 1], not
[NaN, -1].  I can think of some eigenvalue routines that will
break in Octave but work in Matlab...  Fixing them for Octave
would require explicit NaN checks that are _not_ necessary under
IEEE arithmetic.

Jason



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------