🚀 go-pugleaf

In article <ROCKWELL.92Apr15094037@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|Stephen P Spackman:   (sorry about messing up attribution, earlier)
|   |   ||> [... reduction on empty array ...]
|   |   ||> Nono, you missed the point. Some operations (like "+") make
|   |   ||> SENSE for empty arrays, and there you supply the
|   |   ||> appropriate value (0). Others (like "min") only make sense
|   |   ||> on an empty array in an extended domain (for present
|   |   ||> purposes: don't make sense) and so you REQUIRE at least one
|   |   ||> element, ...
|
|Me:
|   |I've been hoping some one else would bring this up, but: what kind
|   |of implementation is this, where you've got a numeric type but no
|   |maximum element of that type?  I wasn't aware that could happen
|   |with a finite set of numbers -- at least, not for the case where
|   |those numbers are members of the set of real numbers.
|
|   That's not the point. The point is that if I say min({}) and you
|   say -32768, you are WRONG.
|
|No kidding.  If your system, or your implementation of sets, only
|allows 16 bit signed integers then the answer should be 32767.  If
|your system allows ieee floating point, then the answer should be
|positive infinity.

Obviously, I meant 32767 (that or I meant max). The point is that the
maximum for the representation and the maximum for the type are
different notions, and that in any case (no matter what IEEE may tell
you) "infinity" is not an integer and it's not a float. It's a domain
extension, and you shouldn't have to rely on them in order to code up
simple notions like min and max.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------