From octave-maintainers-request at bevo dot che dot wisc dot edu  Sun Jul 30 20:52:28 2000
Subject: Re: Ordered NaN on purpose? 
From: Edward Jason Riedy <ejr at EECS dot Berkeley dot EDU>
To: Joao Cardoso <jcardoso at inescporto dot pt>
cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Sun, 30 Jul 2000 18:44:57 -0700

[sending this message to octave-maintainers instead of bug-octave, 
as it wanders away from my original report]

I mention that min([NaN, -Inf]) == NaN, and Joao Cardoso reponds:
 - 
 - Related questions have already been discussed, see for example,
 - 
 - http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1999/204
 - http://www.che.wisc.edu/octave/mailing-lists/help-octave/1999/1259

Thank you greatly.  I don't know how I missed these and am 
quite glad that the issues have been discussed somewhat.  
Before I continue, let me point out that certain people here 
at Berkeley have pretty well convinced me that their views 
on floating-point arithmetic are the right ones, so I have 
some relatively strong views.

The threads also present a few misconceptions (as far as I 
can discern) about the IEEE standards.  First, min and max 
are not defined operations, so the blanket all-operations-on-
NaNs-produce-NaNs statement is irrelevant.  Both Matlab and 
the BLAS return numbers whenever possible.  Unfortunately, 
I can't see where in the upcoming BLAST spec they've 
mentioned this...  I'll try to get a clarification.

Second, not all comparisions between NaNs and numbers produce 
false.  All comparisons typically provided by programming 
languages produce false, but that is not the same.  I don't 
have the 754/854 specs handy, but I do have the 1984 IEEE 
Micro article describing IEEE 854 (the generalization of 754 
to allow base-10 arithmetic).  Section 5 of the paper contains 
the draft IEEE 854 section on comparisons, 5.7.  It also 
contains the table of the 26 distinct comparison operators, 
their results, and whether or not the invalid flag is to be 
raised...  In particular, operations like x .NE y are both 
valid true when either x or y are NaN.  The only other valid
operations are rarely (if ever) accessible through programming
languages, unfortunately.

All that blathering aside, I see the point for both min/max
behaviors.  If you're using NaNs to track errors / unknowns,
then I suppose min([NaN, ...]) should return NaNs.  Since
one of the possible uses espoused by the IEEE authors is
tracking errors, that may make sense.

Having min/max return the min/max _number_ whenever possible
also makes sense.  Consider partial pivoting in a matrix
factorization.  If max returns NaN whenever it exists in the
column, then any time you encounter a NaN, you're hosed.  For
many applications, this may not be a big deal.  Consider a
limited LU preconditioner.  The NaN may not matter; it would
be a shame to waste the rest of the computation.  

Also, porting Matlab code adds more conditional tests, making 
the code uglier.  That makes convincing people to use Octave a
tad more difficult.

So would a patch that does the following be accepted:

  1) Make a global flag for the default min/max behavior.

  2) Add an optional parameter for min/max to override the default.

  3) Make the default be to return a number if at all possible, so
     min([NaN, -Inf]) == -Inf.

By min/max, I mean xmin and xmax in liboctave/lo-mappers.cc, 
{row,col}_{min,max} in dMatrix.cc and CMatrix.cc, and all_integers
in the same files.  Anyone know of other locations?  Note that
all_integers doesn't check for NaNs, but returns max and min vals.

Jason