Re: math.min, math.max

[Tim Hill <drtimhill@...>]

On Apr 9, 2014, at 1:43 PM, Coroutines <coroutines@gmail.com> wrote:

>>> 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.
>>> 
>> 
>> But max(a,b,c) will always return _one_ of the actual values passed in. max() by itself doesn't get passed any values, so generating math.huge out of nothing seems inconsistent as well.
>> 
>> --Tim
>> 
>> 
> 
> I think he's saying that in the context of calculating a max() and
> min() value, negative and positive infinity make sense
> algorithmically?
> 

Understood, and I agree with the logic up to a point. It really comes down to how you define the function. If it’s something like “returns the argument that is …” then I think you would expect it to return _one_ of the arguments passed in, not a brand-new value. In this interpretation, nil or an error for no arguments seems more logical to me. After all, if I asked you to tell me the height of the tallest person in a room, and there was no-one in the room, you wouldn’t tell me “he’s infinitely tall”, you’d say “I can’t do that, there’s no-one in the room!”.

—Tim