Re: math.min, math.max

[Coroutines <coroutines@...>]

On Wed, Apr 9, 2014 at 1:32 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On Apr 9, 2014, at 3:27 AM, 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.
>>
>
> 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?

For math.min(), the initial value you start with (not provided in the
args) has to be a value that will always be replaced to hold true to
the less-than comparison.

local previous = math.huge -- the initial value

for _ = 1, select('#', ...) do
    local v = select(i, ...)
    if v < previous then
        previous = v
    end
end

Conversely, math.max() would have an initial value of -math.huge so
the first comparison will always succeed for whatever number of args
you provide (1 and greater).

If no arguments are provided than the initial value is returned
unmodified -- math.max() -> -math.huge; math.min() -> math.huge

I would expect an invalid argument (non-number) to error(), as it
already does :>