Re: math.min, math.max

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

2014-04-09 19:55 GMT+02:00 Coroutines <coroutines@gmail.com>:
> On Wed, Apr 9, 2014 at 9:43 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 2014-04-09 17:56 GMT+02:00 Andrew Starks <andrew.starks@trms.com>:
>>
>>> If huge or -(huge) were the result of (nil), I probably would not patch it
>>> and instead change the logic in my code to use the new result, but it
>>> doesn't sound like this would be correct.
>>
>> >From the mathematical point of view, max() can only be defined if
>> (a) you know from what ordered set legal values come (b) that set
>> has a smallest element. The moment one allows max to accept any
>> ordered set, there is no useful value that max() can have -- and nil
>> is designed for just that situation. But I would not like to distinguish
>> between max() and max(nil).
>>
>
> I dunno, I wonder if max()/max(nil) -> 'nothing'  would be more appropriate.
>
> Returning nil usually makes sense in error cases where it is followed
> by an error explaining the case

Though possible, the distinction between returning nothing and
returning some nils is messy —  select('#',fct(...)) — and not
accepted practice.