On to Hydro
Mark S. Miller
Fri, 18 Aug 2000 18:59:57 -0700
At 01:41 PM 8/18/00 , Tyler Close 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
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.
> > 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.