Re: IEEE NaN and Trichotomy

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

At 12:02 PM 12/22/92 -0500, Jim Allard wrote:
>Robert Cassels responds:
>
>> 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))
>
>Sorry I missed that conversion.  I guess I hadn't got enough Wheaties or
>something that day.  I think that I've been so immersed in the asymmetry of
>IEEE floats that it didn't occur to me.
>
>> So this choice (making Dylan's comparison operators differ from IEEE
>> comparisons) *was* made with performance issues in mind.
>
>I agree that a single, additional "not" is an insignificant cost.  Perhaps I
>should have sprinkled some smileys in my note?  Arguments about language
>design and politics are similar in that everyone believes they are dead right,
>even though the range of opinions on a topic may be miles wide.  As I've
>mentioned before, I never intend to minimize the architect's difficulties in
>making the trade-offs required to complete a language design, and I do really
>like Dylan.  But if we all agreed all the time what would there be to discuss?
>
>Anyway, you might still find some who would triumphantly point to this one
>"not" instruction and then denigrate high-level languages as always slower
>than macho low-level languages, but my previous performance criticism is now
>reduced to a desire to not give those folks any ground to stand on.  I do
>still beleive arithmetic is one of these litmus tests for the C programmer
>types that you hope to draw to Dylan.

Of course the compiler would turn (not (binary< ...)) into the most
efficient machine instruction(s), which might be a branch-less-or-equal and
wouldn't necessarily need an explicit "not" instruction.  The issue here
isn't what machine instructions get generated (I assume we can write
sufficiently clever compilers), but what the programmer writes to get what
effect.

>As an FYI about my motivation for the comparison implementation options in my
>previous note, I kept looking for a way to avoid giving the "wrong" IEEE
>answer.  I was inclined towards this approach since I felt it was consistent
>with the pains that have been taken to keep Dylan "safe", so I had expected an
>error on NaN comparison.

I have no objection to signalling an exception on NaN comparisons.  (It's
what I did with NaN comparisons for Symbolics machines.)  I haven't looked
at what performance implications that might have on which platforms.  (And
you're concerned about a "not" instruction.  :-)

>> Other issues involved are ease of programmer-defined comparisons...
>
>> 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 agree with the desire for ease of comparison definitions and including the
>math operations in a module is fine.  I still would be a little concerned that
>the subtle difference in behavior between Dylan <= and IEEE-math <= could be a
>source of confusion for novice users.  That was the reason I made the
>suggestion that I did for these methods.  In the absence of binary<= methods,
>they would provide the existing behavior.

I suspect that "novice" users would be confused by the asymmetry of IEEE
comparisons.