Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Exceptions vs NaN/NaI



On May 8 2012, Michel Hack wrote:

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

However, there IS a serious inconsistency/flaw in this area, which
shows itself with operations like 0.0 <= NaN and 0.0 >= NaN.  The
irrational deprecation of trap-diagnose-and-halt means that, in
conventional programming languages, there is a likelihood that both
return false with no reliable error indication.  Java may be the
worst offender, but C is nearly as bad.

But I agree that is a flaw in a different aspect of IEEE 754.

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.)

No, that's misleading to the point of being erroneous.

The benefit arises only if you are comparing with inappropriate
models, such as trap-fixup-and-resume or where it specifies that
the first (and only the first) exception is raised.  With a sane
specification, which raises the exception if any sub-operation
does and leaves the operands in an undefined state, there is no
benefit.  Fortran and other languages have been demonstrating this
for decades.


Regards,
Nick.