Numbers

[bawden.pa@xerox.com]

    Date: Tue, 22 Aug 89 13:16:40 EDT
    From: gls@Think.COM (Guy Steele)
    Pardon my French, but this is completely ridiculous.

I keep hoping that if I rattle you hard enough I may be able to shake you
loose from your position.  Perhaps I'm making progress...

							  You are telling me
    that if I compare the height of a skyscraper, accurately measured by laser
    and known to be within a few microns of 1000 feet tall, with a little kid
    judged by eyeball to be within four inches of three feet tall, then I
    should conclude that I know the larger of the two heights to be 1000 feet
    but only to within four inches.

Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known.  In the common case where
floating point is used, they most definitely do not.  (In the rare case
where interval arithmetic is used, the bounds are known.)  Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet".  The best you can do is "perhaps 1000 feet" and "about four
feet".  The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.

What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet".  (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)

    I agree that in *some* cases the best you can do is return an inexact
    representation of one's best guess.  But sometimes you can tell for sure
    that the answer is exact, even if some of the inputs were inexact.

Perhaps a numerical analyst can look at my program and tell me that for
sure.  Perhaps if I am using interval arithmetic my implementation can tell
me that for sure.  But if I am using floating point, my implementation can
-never- know that for sure.

    In other words, I deny that the inexactness contagion used for + and * is
    appropriate for MAX and MIN.  Why is 549755813888.0 the closest we can
    come?  Only because we have made an arbitrary decision to cast the result
    into a representation that reflects the inexactness of the least exact
    input, regardless of whether that amount of inexactness in fact had
    anything to do with the result computed.

It was not an "arbitrary decision" at all.  549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact.  Its the best we can do.  If we return an
exact number we are potentially returning an -INCORRECT- result.  We don't
know the answer exactly, so we cannot return an exact number.

I would have no objection if we decided to specify that MAX would have to
round up, so that 549755879424.0 was the answer in my example.  One could
argue that this was somehow a better approximation to the true answer
because it passed the `<' test.  But under no circumstances can I see
allowing 549755813889 to be returned, as that would discard the important
information that the answer is not known exactly.