[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
theology; MAX and MIN
Note to Jim Miller: My mail to you has bounced. How did your poll on
this issue come out?
Guy Steele Jr:
Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin. Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.
In the imperfect world I live in, the supremum implied by the phrase
"the best one can do" is even less likely to exist than in the world of
Theologically speaking, Guy's new proposal has the same problem as his old
proposal: It introduces two new demons to undermine a user's faith in
exact numbers. Only the names have changed: now the demons are called
LARGEST and SMALLEST. The damage done by these two procedures won't be
ameliorated by having exactness-preserving SUP and INF as well. For
simplicity, I say that if MAX and MIN, by whatever names, are going to be
exceptions to the perfect rules of exactness, then let's just acknowledge
them as exceptions and to hell, theologically speaking, with the sinfully
striving exactness-preserving versions.
Guy Steele Jr:
But my point of view is that the MAX operation per se, like other C
operators is *not* polymorphic. They operate only on two ints or
two floats. The type mechanism enforces this requirement by inserting
coercions; the point is that these coercions are outside the control
of the implementation of the operation itself, and therefore not
properly a part of them. In exactly the same way that max(2.5, 1000)
in an int context ends up having a coercion inserted, so the coercion
that converts 1000 to a float is artificially inserted.
It doesn't matter how you look at it. My point is that, contrary
to some recent discussion in RRRS-AUTHORS, experience with mainstream
programming languages has conditioned programmers to expect expressions
like (MAX 2.5 1000) to evaluate to an inexact number. I pointed this
out to dispose of a bogus argument, not to argue that programmers'
expectations should decide the issue. Expectations formed by other
languages aren't necessarily met by arithmetic in Scheme, precisely
because arithmetic in Scheme is more generic (polymorphic, if you will)
than in other languages.