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

*To*: gls@think.com*Subject*: Numbers*From*: bawden.pa@xerox.com*Date*: Mon, 21 Aug 89 17:24 PDT*Cc*: rrrs-authors@mc.lcs.mit.edu*In-Reply-To*: <8908211534.AA29201@verdi.think.com>*Line-Fold*: no

Date: Mon, 21 Aug 89 11:34:37 EDT From: Guy Steele <gls@think.com> I'm back from an exhausting, and therefore very restful, vacation. Back into the fray! I was wondering why I hadn't heard from you. I couldn't imagine that you had given up the argument! Here is a new proposal. Given a set of points within a partial order, there are two interesting kinds of "max"-like operation. One is to find some point (not necessarily within the set) that is >= all points in the given set; this is SUP.... Another is to find some point in the set such that no point in the set is > that point.... But the version of MAX I am advocating isn't either of these! I would allow: (max 1.0 549755813889) ==> 549755813888.0 Where presumably (< 549755813888.0 549755813889) is true. Thus MAX can return an object that, according to `<', is smaller than one of the arguments. Now I'm sure that about half of you are shouting at your terminal about how I couldn't -possibly- mean that, but I do. Understand me once and for all: INEXACT NUMBERS ARE NOT NUMBERS INEXACT NUMBERS ARE NOT NUMBERS INEXACT NUMBERS ARE NOT NUMBERS They do not obey the rules followed by numbers, because they cannot. Inexact numbers only represent our -approximate- -knowledge- about numbers. In (max 1.0 549755813889) ==> 549755813888.0 we strongly suspect that the first number is 1, but we don't know for sure. Thus we strongly suspect that the answer is 549755813889, but again we don't know for sure (the first number could have actually been 549755813890). Since we don't know the answer for sure, we must return an inexact representation of our best guess. 549755813888.0 is the closest we can come. (The next larger might be 549755879424.0, assuming 23 bits of floating point precision, which is not very close at all.) Indeed, we could -specify- that MAX always ``round up'' in the inexact case so that the result always appears greater (accroding to `<') than any of the arguments. This would be similar to specifying that `<' must always behave transitively. It would be a feeble attempt on our part to paper over the ugly fact that -in- -general-, inexact numbers do not obey the axioms of arithmetic.

**Follow-Ups**:

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

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