On to Hydro

[Mark S. Miller]

At 01:41 PM 8/18/00 , Tyler Close wrote:
>Markm wrote:
> > In the next release, all integers respond to
> > isNaN/0 with false.)
>
>Does this not hint to you that maybe E's current design for comparison
>operators is a hack?

I didn't claim it isn't a hack.  But I'll stick with it as long as all 
alternatives seem worse. ;)


>The other problem with pushing everything through one method,
>compareTo(), is that it forces you to have a single contract for all
>the comparison operators. I think I've presented a very good solution
>to the partial vs total ordering problem that E has. Do you have a
>solution for it using the compareTo() paradigm?

No.  But having partially ordered elements respond to "<=", but not respond 
to "<", freaks me out.  Also, since floating point values are only partially 
ordered, your proposal would have floating point values not respond to "<".  
This is unacceptable.

However, I just remembered and confirmed a fact that makes integrated 
support for floating point even more distressing:

     ? NaN <=> NaN
     # value: false

     ? NaN == NaN
     # value: true

The first shows that E correctly conforms to IEEE, but this also means 
IEEE floating point values aren't even a partial order.  I'm not 
defending this, but I'm also going to stick as close to IEEE as Java does.  
I don't pretend to have enough interest or expertise in floating point to 
take on the task of designing a coherent alternative to IEEE.  This stuff is 
*hard*.

How does Java have its IEEE and its container behavior too?  To expand on 
what Tyler said, Java containers deal with instances of "java.lang.Double", 
and java.lang.Double has a container friendly contract.  However, Java's 
"double" scalars have an IEEE friendly contract.  For E, the price of using 
two data types is too high.  E doesn't even have other floating precisions, 
or precision-limited integers.


>Markm wrote:
> > previous discussion of -0.0.  (Tyler, both -0.0 and 0.0
> > must denote the same
> > real number, as there is only one real number they could
> > denote: the one
> > called zero.  Otherwise, what real number would you say
> > -0.0 denotes?)
>
>I'd say that it denotes the number called "negative zero" (and that
>0.0 denotes the number called "positive zero"). The Kahan paper seemed
>quite clear to me on this point. There are two zeroes.

I've downloaded and skimmed the Kahan paper, and see only the claim, which 
of course I agree with, that there are two zero *numerics*.  However, the 
standard's (and the paper's) notion of "representable numbers" I believe 
corresponds to the normal Denotational Semantics notion of a denotation: 
except for infinities and NaNs, every floating point value denotes some 
*real number*, as mathematicians define real number.  On the real number 
line, there is only one zero, so both floating point zero values denote the 
same real number.  The "representable numbers" are those real numbers that 
are denoted by some floating point value.

Btw, the Kahan document also says:

>Note that +0 and -0 are distinguishable and follow obvious rules specified 
>by IEEE 754 even though floating-point arithmetical comparison says they are 
>equal; there are good reasons to do this, some of them discussed in my 1987 
>paper “ Branch Cuts ... .” The two zeros are distinguishable arithmetically 
>only by either division-by-zero (producing appropriately signed infinities) 
>or else by the CopySign function recommended by IEEE 754 / 854.


Sometimes, language design is just hard.


         Cheers,
         --MarkM