[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ordered NaN on purpose?
From: |
Edward Jason Riedy |
Subject: |
Re: Ordered NaN on purpose? |
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
- Re: Ordered NaN on purpose?,
Edward Jason Riedy <=