Numbers and Pork Rinds

[bawden.pa@xerox.com]

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

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?
I don't follow this.

		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.