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

*To*: gls@think.com*Subject*: Numbers*From*: bawden.pa@xerox.com*Date*: Tue, 22 Aug 89 14:40 PDT*Cc*: rrrs-authors@mc.lcs.mit.edu*In-Reply-To*: <8908221716.AA01133@verdi.think.com>*Line-Fold*: no

Date: Tue, 22 Aug 89 13:16:40 EDT From: gls@Think.COM (Guy Steele) Pardon my French, but this is completely ridiculous. I keep hoping that if I rattle you hard enough I may be able to shake you loose from your position. Perhaps I'm making progress... You are telling me that if I compare the height of a skyscraper, accurately measured by laser and known to be within a few microns of 1000 feet tall, with a little kid judged by eyeball to be within four inches of three feet tall, then I should conclude that I know the larger of the two heights to be 1000 feet but only to within four inches. Inexact numbers do not necessarily contain a representation of the precision with which a quantity is known. In the common case where floating point is used, they most definitely do not. (In the rare case where interval arithmetic is used, the bounds are known.) Thus in a floating point implementation of inexact numbers, you cannot represent the concepts of "within a few microns of 1000 feet" or "within four inches of three feet". The best you can do is "perhaps 1000 feet" and "about four feet". The MAX of these two is "perhaps 1000 feet" -- any arguments about the precision ("within a few microns of 1000 feet" vs. "within four inches of 1000 feet") are in the province of a numerical analyst to reason about. What I was -actually- claiming was that the MAX of "exactly 1000 feet" and "about four feet" is "perhaps 1000 feet". (In an implementation that used interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet" and "within four inches of three feet" and get "exactly 1000 feet", but in -general-, inexact arithmetic does not have this ability.) I agree that in *some* cases the best you can do is return an inexact representation of one's best guess. But sometimes you can tell for sure that the answer is exact, even if some of the inputs were inexact. Perhaps a numerical analyst can look at my program and tell me that for sure. Perhaps if I am using interval arithmetic my implementation can tell me that for sure. But if I am using floating point, my implementation can -never- know that for sure. In other words, I deny that the inexactness contagion used for + and * is appropriate for MAX and MIN. Why is 549755813888.0 the closest we can come? Only because we have made an arbitrary decision to cast the result into a representation that reflects the inexactness of the least exact input, regardless of whether that amount of inexactness in fact had anything to do with the result computed. It was not an "arbitrary decision" at all. 549755813888.0 is closest because we only have 23-bit floating point to represent inexact numbers, and the answer must be inexact. Its the best we can do. If we return an exact number we are potentially returning an -INCORRECT- result. We don't know the answer exactly, so we cannot return an exact number. I would have no objection if we decided to specify that MAX would have to round up, so that 549755879424.0 was the answer in my example. One could argue that this was somehow a better approximation to the true answer because it passed the `<' test. But under no circumstances can I see allowing 549755813889 to be returned, as that would discard the important information that the answer is not known exactly.

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

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