Numbers and Pork Rinds

[Guy Steele <gls@think.com>]

   Date: Wed, 23 Aug 89 17:33 PDT
   From: bawden.pa@xerox.com

       Date: Wed, 23 Aug 89 14:25:31 EDT
       From: gls@Think.COM (Guy Steele)
       Here is where the cart may be before the horse.  I'll let you inspect the
       *types* of the arguments up front in any case.  Are you then deciding a
       priori to use floating-point to represent the result only on the basis of
       the argument types, without regard to the values involved?  Or do you
       entertain the possibility that the type (or representation) of the result
       may depend on the specific values of the arguments?  I am arguing for the
       latter.

   Of course the type of the answer may depend on more than the datatype of
   argument.  Consider the case of `*'.  In general (* <inexact> <exact>)
   yields an inexact number.  But in the case of (* <inexact> 0) you may
   return an exact 0.  If your implementation used interval arithmetic, then
   (MAX <inexact> <exact>) may well be able to return an exact number, given
   the bounds contained in the inexact argument:

     (MAX #<Interval 3 through 5> 10)  ==>  10

     (MAX #<Interval 9 through 11> 10)  ==>  #<Interval 10 through 11>

   BUT IN THE CASE WHERE FLOATING POINT IS USED I do not believe there is any
   case where an exact answer may be returned if one of the arguments is
   inexact.

Very well; we are making progress.  You do admit that in some circumstances,
in some implementations, it may make sense for (max 4.0 1000) to return an
exact 1000, say in the case where "4.0" is interpreted by the reader to
mean "the interval from 3.95 to 4.05".

My argument, then, is as follows.  Floating-point is indeed so screwed up
that the implementor cannot a priori regard them as intervals or as
anything else interesting, and therefore cannot return an exact result for
the supremum operation.  HOWEVER, in some cases the user, knowing the
properties of the floating-point arithmetic, can with his additional
understanding determine that they may be regarded as intervals (or
something close to that) for his purposes.  Therefore the user should be
given a choice.  LARGEST and SMALLEST may be useful alternatives; *but* I
have also managed to argue that their use is not portable.  (On the other
hand, many uses of inexact arithmetic will be nonportable in precisely the
same manner, so to this we should not attach too great a stigma.)

       Presumably when you say "perhaps 1000 feet" you mean something different
       from "perhaps 4 feet", or otherwise you would not bother; you would have a
       single inexact number called "perhaps".  There is some level of confidence
       that leads you to say "perhaps 100" in preference to any other inexact
       result.  Am I to regard an inexact number as a probability distribution
       (whose shape I may know nothing about)?

   No, an inexact number is not necessarily a probability distribution
   (although that might be an interesting representation to explore).  I can't
   tell you what it is in general.  Sorry.  We aren't specifying the behavior
   of inexact numbers here.

I meant "probability distribution" to be not an implementation
representation, but a conceptual model that might cover all representations
in one way or another.  But that's a side point; you didn't address my main
question.  If inexactness is considered by the Scheme standard merely to be
a scarlet letter indicating that a value is in a state of sin and is
therefore not to be trusted (for inexact arithmetic, while required to
strive for "high quality", has no particular portable requirements), then I
want to know how it is that you can ever think that "perhaps 1000" can ever
be said rather than merely "perhaps"; in other words, without some further
requirements on, or knowledge of, the quality of a particular
implementation, why is it not my duty to regard *every* inexact number as
representing merely "perhaps"?

   All I care about is that MAX not return an exact answer unless the
   implementation really -knows- that that exact number is the correct answer.
   That's all I care about.  Read my lips.

Okay.  Up to now I had understood you additionally to argue that
the implementation can't ever know that for LARGEST, and therefore
LARGEST is a bogus concept.  Now that we have found a circumstance
when the implementation *can* know, we have proved that LARGEST is
not bogus.  A separate argument now concerns whether it is useless.

But I think I am about to run out of steam.  Alan and I have aired
our views pretty thoroughly, tying up a lot of mailboxes in the process.
Hey, all you out there: does anyone else care?  Has anyone's mind been
changed as a result of our discussion?


--Guy