# Numbers and Pork Rinds

```    Date: Thu, 24 Aug 89 12:28:42 EDT
From: gls@Think.COM (Guy Steele)

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

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

This is not a new admission on my part.  I'm pretty sure I've be saying
parenthetically all along that if you use interval arithmetic you might be
able to return an exact answer.  I may have slacked off on beating that
particular point recently because it gets rather tiresome to be constantly
decorating my arguments with little qualifications of the form: "(assuming
we are using floating point)" and "(unless you are using interval
arithmetic or continued fractions)".

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

No only are uses of LARGEST and SMALLEST non-portable, but LARGEST and
SMALLEST are also very easy for the user to write himself.  In fact, a user
with a sufficient understanding of the properties of the inexact arithmetic
in a given implementation may be able to write all kinds of non-portable
things that work correctly to solve his problem -- but that doesn't mean
that we should be putting such things in the language.

...  We aren't specifying the behavior of inexact numbers here.

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

In the absence of any other constraints on the behavior of inexact numbers,
an implementation in which there is just -one- inexact number would be
legal.  We could even call it "perhaps".  I'm not sure this would be any
more useful than an implementation that didn't have any inexacts at all and
signalled an error when it couldn't produce an exact answer.  Now I don't
recall what set of constraints are currently in the draft report, but there
was a time when some language ruled out having just #<Perhaps>.  But none
of this has anything to do with the issue of MAX/MIN, which is purely a
consequence of the desired properties of -exact- numbers.

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.

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.

See above.  I have tried very hard to -never- say that the implementation
"can't ever know" anything without qualifying it by saying: "assuming
floating point".  I don't know what it means for LARGEST to be a "bogus
concept".  All I know is that it isn't the right procedure to give to the
users as MAX.

Now that we have found a circumstance
when the implementation *can* know, we have proved that LARGEST is
not bogus.

Huh?  The circumstances when the -implementation- can know the exact result
from a call to MAX with an inexact argument are when something other than
floating point is being used.  But what does this have to do with LARGEST?

A separate argument now concerns whether it is useless.

Since the user can write it himself so easily it better be pretty damn
usefull before we should put it in the language.

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?

I'll bet most people haven't been paying attention.  I fully expect to have
to repeat this entire argument every six months for the rest of my life.

```