🚀 go-pugleaf

In article <ROCKWELL.92Apr15002308@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> Jim Giles:
|>    ||> [... 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, ...
|> 
|> 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.

Well, you quoted my name on someone else's remarks.  In fact, I was
disagreeing with the quote attributed to me above.  

As for maximum elements of a type, what has that got to do with the 
issues raised here?  The correct return of `min' applied to an empty 
is _not_ the maximum possible value of the type!  That implies that
the array wasn't empty but it's minimum element had that value.  NAN
(not a number) might be an appropriate return.  The user should have
control over this explicitly though.  The user should decide what
should be done if the array argument to a reduce is empty.

J. Giles