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

*To*: will@cs.uoregon.edu*Subject*: MIN and MAX (long message)*From*: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>*Date*: Tue, 8 Aug 89 18:22:26 pdt*Cc*: rrrs-authors*In-Reply-To*: will@cs.uoregon.edu's message of Mon, 7 Aug 89 16:02:42 PDT <8908072302.AA04327@spencer.cs.uoregon.edu>*Reply-To*: jinx%hpesogg@sde.hp.com

Bill Rozas: As far as I understand it (and GJS agrees with me), the example Will shows could only be correct in an implementation where (>= 9.999999999999998e99 #e1e100) is true. If it isn't, the implementation of MAX/SUP is in error. Not as I understand it. I intended for this example to illustrate what happens in an implementation that uses IEEE 64-bit floating point to represent inexact reals, but I goofed (because of a bug in the least significant bit of MacScheme's implementation of EXACT->INEXACT for large numbers). A better example is (MAX 1.4 #e1e200) ==> 9.99999999999999969733e199 The problem with this is that (MAX 9.99999999999999969733e199 #e1e200) ==> 9.99999999999999969733e199 while the implementation can still distinguish (in the sense of < and >) between both arguments. This seems wrong! I think that requiring MAX to round up would be like requiring (+ x y) to return a number greater than x whenever y is positive. It sounds plausible at first, but would tend to make computations less accurate. I have to admit, given the difficulty of coming up with any real-world examples where MAX returns a value that is not equal to one of its arguments, that a difference in the least significant bit in such cases would probably be of very little consequence, and it might make someone's mother happy. I think your analogy is pushing it a bit. I don't expect inexact + to follow any particular ordering properties. In fact, we know that floating point addition (the "usual" implementation) rounds towards even, and there are (or so I'm told) good reasons for this. I do expect some ordering properties out of MAX/SUP, however. Otherwise I would not be using it at all. The rule that GJS and I like, namely that MAX/SUP should return the smallest value >= all of its arguments, makes it more predictable than yours.

**References**:**MIN and MAX (long message)***From:*will@cs.uoregon.edu

- Prev by Date:
**sequential order of evaluation** - Next by Date:
**First BASH Meeting** - Prev by thread:
**MIN and MAX (long message)** - Next by thread:
**MIN and MAX (long message)** - Index(es):