Re: IEEE NaN and Trichotomy

[Robert A. Cassels <cassels@cambridge.apple.com>]

>Being somewhat of a late-comer to the discussion I don't know if this has been
>addressed before, but I wanted to address my surprise at the explicit rejection
>of IEEE NaN comparison behavior in Dylan.
>
>On pages 75 and 147 there are mentions that floats follow IEEE conventions
>except within comparisons, where the IEEE behavior would harm trichotomy and
>therefore cannot be used.  No alternate behavior is described.  Though I do not
>know what within the language depends on trichotomy and so cannot know the
>fallout of this suggestion, I would urge the Dylan designers to revisit this
>issue and consider adopting a fully compliant IEEE float behavior.
>
>I also have a suggestion (which may be completely wrong) that partial orderings
>could be handled if the possibility is allowed of users optionally writing more
>binaryX comparitor methods, which would be used by comparitors other than = and
>< when available, but still falling back to the two required comparitors when
>the optional ones weren`t supplied.
>
>My concerns about dropping IEEE NaN comparisons maninly have to do with
>implementation speed issues made difficult by this choice.  Other concerns for
>me would be getting Dylan users to understand a non-compliant behavior and
>Dylan missing out on industrial standards and practices that tie-in with the
>IEEE standard.
>
[Much detail elided.]
>
>Any thoughts or interest on this?

The idea behind requiring trichotomy is to allow all comparisons to be done
with a single call to binary< or binary=:
  (<= a b) => (not (> a b)) => (not (binary< b a))

Of course, introducing a NOT makes this <= differ from IEEE comparison,
since all comparisons involving NaNs are supposed to return #f.  The
presumption is (and we should be more explicit about this in the book) that
the implementor will use the normal IEEE operations for binary< and
binary=.  Then <=, >=, etc. will work correctly so long as no input is a
NaN, and will give the (IEEE) wrong answer when presented with a NaN.

So this choice (making Dylan's comparison operators differ from IEEE
comparisons) *was* made with performance issues in mind.  Other issues
involved are ease of programmer-defined comparisons (the Dylan programmer
only defines 2 comparison methods, rather than 7 or 16 or however many IEEE
ones might have to be defined), and possibility of clever compiler
optimizations (dropping trichotomy limits the inferences possible from (> b
a)).

I think that the majority of Dylan programs and programmers will benefit
from the current definition of comparison operations, which agrees with the
usual mathematical interpretation.  That said, your arguments about use of
NaNs are compelling.  So I'd propose adding an IEEE library to Dylan which
defines IEEE comparison operators in the way you suggest -- providing
default methods for binary<= and binary>=, etc.  The IEEE library could
define all the other IEEE-required functions, too.  Note that the Dylan
module system would allow you to choose whether to use <, <=, etc. (the
Dylan names) to refer to the IEEE comparisons, or to rename them to names
which don't conflict with the standard names.

I haven't thought about whether partial order comparisons are the same or
different from IEEE comparison operators.