MIN and MAX (long message)

```    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.

```