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

*To*: bawden.pa@xerox.com*Subject*: Numbers and Pork Rinds*From*: Guy Steele <gls@think.com>*Date*: Thu, 24 Aug 89 12:28:42 EDT*Cc*: gls@think.com, rrrs-authors@mc.lcs.mit.edu*In-Reply-To*: bawden.pa@xerox.com's message of Wed, 23 Aug 89 17:33 PDT <19890824003336.4.ALAN@ROCKY.parc.xerox.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

**Follow-Ups**:**Numbers and Pork Rinds***From:*bawden.pa@xerox.com

**Numbers and Pork Rinds***From:*Luddy Harrison <harrison@s45.csrd.uiuc.edu>

**References**:**Numbers and Pork Rinds***From:*bawden.pa@xerox.com

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