Re: math.min, math.max

[Andrew Starks <andrew.starks@...>]

On Wednesday, April 9, 2014, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-04-09 12:15 GMT+02:00 Oliver Kroth <oliver.kroth@nec-i.de>:
> > Is this so?
> >
> > I would expect the minimum or maximum element of the argument list to be
> > returned as result.
> > With an empty list, I would not be confused to get nil.
>
> It's the same principle by which when n<1,
>
>    1 + 2 + 3 + ... + n
>
> evaluates to 0  and
>
>    1 * 2 * 3 * ... * n
>
> evaluates to 1.
>
> max satisfies relationships like: max(a,b,c,d) = max(max(a,b),max(c,d)),
> no matter how you split up the arguments. For a consistent definition
> of max(), you need max(a,b,c,d) = max(max(),max(a,b,c,d)). But the
> only value of x for which always y = max(x,y) is x=-math.huge.
>
> At present you don't get nil, you get an error.

I would need it to return nil. 

This is mathematically correct. Another way to look at it is that the max or min of the empty set is nil, which is not correct for math purposes, but does cover the use cases that I use it for. 

Example: I have many scatter lists, stored in ordered sequences, representing key frames that are connected in a graph. My need to know the next closest key frame. If I'm past all remaining key frames, nil is the response I'm looking for. Math.huge works, but nil is more natural, to me. 

I guess I could use it this way though, and it's better than what I have to do now (always patch it) and I don't like arguing with Dirk...

I also imagine that this would be slower than current behavior, but in a dynamic language, error is not consistent with my expectations. But this is a common experience with all of math: numbers *only*. No "number like* entities allowed, except string. (? I should check this...)

-Andrew