On to Hydro
Fri, 18 Aug 2000 16:41:13 -0400
> 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?
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?
I am not sure, but I would expect that returning a Double from your
compareTo method will also make a measurable difference in the runtime
of sorting algorithms. I would not be surprised if it was a factor of
2. Not a compelling reason, but definitely another hint.
Just to clarify the interfaces that I proposed:
boolean within(Object x); // Is <=
boolean includes(Object x); // Is >=
interface TotallyOrdered extends PartiallyOrdered
boolean before(Object x); // Is <
boolean after(Object x); // Is >
> 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. Why do you
insist that there is only one? I see no logical reason to insist that
there can be only one zero in a floating point arithmetic. Moreover,
the floating point arithmetic that you are using goes to great lengths
to ensure that these zeroes are, and remain, separate numbers. The
library that you are implementing with, JDK, also ensures that the two
zeroes are separate numbers. See the JDK1.3 javadoc for Double. What
other signs are you looking for?
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com