# Numbers and Pork Rinds

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

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.

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.