[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: gls@think.com*Subject*: Numbers and Pork Rinds*From*: bawden.pa@xerox.com*Date*: Thu, 24 Aug 89 17:37 PDT*Cc*: rrrs-authors@mc.lcs.mit.edu*In-Reply-To*: <8908241628.AA00798@verdi.think.com>*Line-Fold*: no

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.

**Follow-Ups**:**Numbers and Pork Rinds***From:*"Guillermo J. Rozas" <jinx@hpesogg.hp.com>

**References**:**Numbers and Pork Rinds***From:*Guy Steele <gls@think.com>

- Prev by Date:
**Revised WITH-VALUES and VALUES (I think we are near agreement!)** - Next by Date:
**Programmer-defined data types** - Prev by thread:
**Numbers and Pork Rinds** - Next by thread:
**Numbers and Pork Rinds** - Index(es):