On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson <dicki...@gmail.com> wrote:
> On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
> <matt...@woodcraft.me.uk> wrote:
>> In CPython, the builtin max() and min() have the property that if there
>> are items with equal keys, the first item is returned. From a quick look
>> at their source, I think this is true for Jython and IronPython too.
>
> It's actually not clear to me that this behaviour is ideal; it might
> make more sense to have max() return the first item among equal
> largest elements, and min() return the last item. That way, the
> special case of two operands has the nice property that (max(x, y),
> min(x, y)) is always either (x, y) or (y, x), rather than being
> possibly (x, x) or (y, y). (That is, id(max(x, y)) and id(min(x, y))
> are id(x) and id(y) in one order or the other.)
>
> The max and min methods for the Decimal module take care to work this
> way, for example:
>
>>>> x, y = Decimal(2), Decimal('2.0')
>>>> x.max(y), x.min(y)
> (Decimal('2'), Decimal('2.0'))
>
> But:
>
>>>> max(x, y), min(x, y)
> (Decimal('2'), Decimal('2'))
>
Decimal may actually have this backwards. The idea would be that
min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a
stable sort, then, max of equivalent elements would return the last
element, and min the first. According to Alex Stepanov, this helps
some with composing these small order statistics into larger
stably-ordered functions.
I do think Decimal.max's answer is better than the builtin's answer,
and that the incremental benefit from returning the last instead of
first is pretty small.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
