On to Hydro

[Tyler Close]

Markm wrote:
> 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. ;)

Ahhh... a ray of hope.

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

Until you do, it fails your test. Broken is broken.

>  But having partially ordered elements respond to "<=",
> but not respond
> to "<", freaks me out.

It actually seems very natural to me. In order to search a linear
container, you need to have either the "<", or the ">", operator. A
partial ordering does not let you search a linear container, and so
does not provide either the "<", or the ">" operator. Pretty slick,
no?

>  Also, since floating point values
> are only partially
> ordered, your proposal would have floating point values not
> respond to "<".
> This is unacceptable.

Huh? With the exception of NaN, floating point values have a total
ordering. In one of my previous posts, I explained how we should
handle this. IEEE lets you raise an exception on NaN, so let's do it.
You can't get anywhere from NaN (NaN and any op is NaN), so it just
makes sense to raise an exception anyways.

> 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

"Doc, it hurts when I do this." "So don't do that!". See above.

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

At this point, I am going to point out that there are two separable
issues here. The first is "How does E support the comparison
operators?" and the second is "How does E order floating point
values?". Both the current and the proposed solutions for comparison
operators need a solution for the ordering of floats.

Minus NaN handling, I think Java's Double class presents a fine
solution for the ordering of floating point values. Choosing to use
Java's Double class qualifies for "sticking 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*.

Don't overstate the case. We're not talking about replacing IEEE.
We're talking about which implementation of it we choose. Java's
Double class is a perfectly valid choice for E to make.

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

java.lang.Double is IEEE friendly. If we throw an exception on NaN,
then the only difference is the -0.0 < 0.0 behaviour. I don't know how
big a deviation this represents. Can we send an email to Kahan? He
seemed pretty concerned with how programming languages deal with
floats. Maybe he would be glad to give an opinion.

> >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?)

Something I forgot to point out. Since when does E have reals? E does
not, and cannot, have reals. It can only deal in floats. Why should we
even be thinking about what reals mean? We should only be thinking
about what floats mean.

> Sometimes, language design is just hard.

So let's ask for help. Send an email to Kahan.

Tyler


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com