Re: IEEE NaN and Trichotomy

[jra@gensym.com (Jim Allard)]

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.

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.

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

Jim

-------------------------------------------------------------------------------
Jim Allard                                        jra@gensym.com
Manager of Languages, Interpreters, & Compilers   (617) 547-2500
Gensym Corporation
125 CambridgePark Drive
Cambridge, MA  02140
-------------------------------------------------------------------------------