Re: math.min, math.max

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

On Wednesday, April 9, 2014, Coroutines <coroutines@gmail.com> wrote:
> 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 :>

There is at least one case where nothing is adjusted to nil (__index) and another where nothing given as an argument is error (type). But there are good reasons for this, even if I'd have to guess at what they are. (I wish it weren't true for __index. You could store nil as a value in a table, if it were, but no biggie)

Other than that, I've always treated nil and nothing as the same, except when working with select. 

My thought is that nil is essentially "no value" in this context. The max  / min of no value or nil is nil, in my world. So, my version of max:

max(nil, 3, my_number_like_object_that_is_2) --> 3

max()

--> nil

Max(nil)

-->nil

Basically, nil has no effect, no values return nil, check the metamethod if it isn't a number. 

I'm sure it's crippling-ly slow. :)

-Andrew