[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MIN and MAX (long message)
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.