Re: math.min, math.max

[Dirk Laurie <dirk.laurie@...>]

2014-04-09 17:42 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>> Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> > 1. If the argument list always has a first element, there is no reason to
>> > stay with numbers. Anything for which less-than is defined can work.
>>
>> This could be useful! Actually, if you asked me if this was already
>> the behavior, I wouldn't know it for sure.
>
> This is how it is implemented now (for the next work version). The
> main motivation is for working correctly with integers, too:
>
>> math.max(4611686018427387901, 461168601842738790)  --> 4611686018427387901
>
> The original version would lose precision in that case.

Two facts, if true, would be useful to have in the documentation
rather than left as implementation details.

1. The returned value is always one of the given arguments.
2. A later element is preferred over an earlier element only in the case
of strict inequality as tested by the standard Lua < operator.

Fact 1 would imply that max(nil) returns nil, and could be
a motivation for max() to return no value instead of raising
an error.

Fact 2 is necessary for authors of __lt metamethods.