Re: Exceptions vs NaN/NaI
Dmitri Nadezhin wrote:
> Unfortunately, such compareTo is inconsistent
> with comparison operations "==", "<", ">", "<=", ">=" :
> d == Double.NaN is always false;
> d < Double.NaN is always false;
> but
> compare(Double.NaN, Double.NaN) == 0;
> compare(0.0, Double.NaN) == -1 .
> This inconsistence is unavoidable with 754-types.
This is not an inconsistency or flaw with 754 -- it is quite
deliberate, if "compare()" is indeed defined to be TotalOrder.
You should also have
compare(-0.0, +0.0) == -1
but
-0.0 == +0.0
The fact that NaN compares Unequal to anything, including itself,
is a deliberate FEATURE of 754 for ordinary comparisons. In fact,
it compares Unordered when that can be reflected (e.g. in machine
instructions with at least a four-valued condition code), or signals
an exception for the "noisy" family of comparisons.
I would think that having a NaN concept for ExtendedRational could
be useful as an alternative to throwing an exception. The benefit
arises from the ability to defer exceptions by exploiting the NaN
propagation rules. This can be a big performance gain in parallel
applications. (Presumably Dmitri's ExtendedRational throws an
exception when dividing zero by zero.)
To get back to P1788, there is indeed less of a need for NaN or NaI
than in plain FP arithmetic. They are only used for "cross-domain"
functions, i.e. functions that return a number from an interval, or
an interval from numbers or strings -- when there is no valid number
or interval that satisfies the function definition. Everything else
can be handled with decorations, Empty and Entire.
The question of whether an environment that supports exceptions can turn
ALL instances that would have yielded NaN or NaI into an exception is a
valid one, and I have a simple answer: of course it can, if only by the
subterfuge that NaN and NaI *are* supported, but that any attempt to look
at them (which is outside the scope of 1788) triggers an exception!
Michel.
---Sent: 2012-05-08 04:00:47 UTC