Numbers

[Guy Steele <gls@think.com>]

   Date: Mon, 21 Aug 89 17:24 PDT
   From: bawden.pa@xerox.com

       Date: Mon, 21 Aug 89 11:34:37 EDT
       From: Guy Steele <gls@think.com>
       I'm back from an exhausting, and therefore very restful, vacation.
       Back into the fray!

   I was wondering why I hadn't heard from you.  I couldn't imagine that you
   had given up the argument!

       Here is a new proposal.  Given a set of points within a partial order,
       there are two interesting kinds of "max"-like operation.  One is to find
       some point (not necessarily within the set) that is >= all points in the
       given set; this is SUP....

       Another is to find some point in the set such that no point in the set is >
       that point....

   But the version of MAX I am advocating isn't either of these!  I would
   allow:

     (max 1.0 549755813889)  ==>  549755813888.0

   Where presumably (< 549755813888.0 549755813889) is true.  Thus MAX can
   return an object that, according to `<', is smaller than one of the
   arguments.

   Now I'm sure that about half of you are shouting at your terminal about how
   I couldn't -possibly- mean that, but I do.  Understand me once and for all:

			 INEXACT NUMBERS ARE NOT NUMBERS

			 INEXACT NUMBERS ARE NOT NUMBERS

			 INEXACT NUMBERS ARE NOT NUMBERS

   They do not obey the rules followed by numbers, because they cannot.
   Inexact numbers only represent our -approximate- -knowledge- about numbers.
   In

     (max 1.0 549755813889)  ==>  549755813888.0

   we strongly suspect that the first number is 1, but we don't know for sure.
   Thus we strongly suspect that the answer is 549755813889, but again we
   don't know for sure (the first number could have actually been
   549755813890).  Since we don't know the answer for sure, we must return an
   inexact representation of our best guess.  549755813888.0 is the closest we
   can come.  (The next larger might be 549755879424.0, assuming 23 bits of
   floating point precision, which is not very close at all.)

   Indeed, we could -specify- that MAX always ``round up'' in the inexact case
   so that the result always appears greater (accroding to `<') than any of
   the arguments.  This would be similar to specifying that `<' must always
   behave transitively.  It would be a feeble attempt on our part to paper
   over the ugly fact that -in- -general-, inexact numbers do not obey the
   axioms of arithmetic.

I did misunderstand.  Thank you for correcting me on this point.  Now:

Pardon my French, but this is completely ridiculous.  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.

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.

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.

--Guy