[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*: Wed, 23 Aug 89 17:33 PDT*Cc*: rrrs-authors@mc.lcs.mit.edu*In-Reply-To*: <8908231825.AA13164@verdi.think.com>*Line-Fold*: no

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. That's all I care about. Read my lips.

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

**References**:**Numbers***From:*Guy Steele <gls@think.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** - Next by thread:
**Numbers and Pork Rinds** - Index(es):