MIN and MAX (long message)

["Guillermo J. Rozas" <jinx@hpesogg.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.