[Python-ideas] [Python-Dev] minmax() function returning (minimum, maximum) tuple of a sequence

[Tal Einat]

On Mon, Oct 11, 2010 at 1:17 AM, Steven D'Aprano wrote:
> On Mon, 11 Oct 2010 05:57:21 am Paul McGuire wrote:
>> Just as an exercise, I wanted to try my hand at adding a function to
>> the compiled Python C code.  An interesting optimization that I read
>> about (where? don't recall) finds the minimum and maximum elements of
>> a sequence in a single pass, with a 25% reduction in number of
>> comparison operations:
>> - the sequence elements are read in pairs
>> - each pair is compared to find smaller/greater
>> - the smaller is compared to current min
>> - the greater is compared to current max
>>
>> So each pair is applied to the running min/max values using 3
>> comparisons, vs. 4 that would be required if both were compared to
>> both min and max.
>>
>> This feels somewhat similar to how divmod returns both quotient and
>> remainder of a single division operation.
>>
>> This would be potentially interesting for those cases where min and
>> max are invoked on the same sequence one after the other, and
>> especially so if the sequence elements were objects with expensive
>> comparison operations.
>
> Perhaps more importantly, it is ideal for the use-case where you have an
> iterator. You can't call min() and then max(), as min() consumes the
> iterator leaving nothing for max(). It may be undesirable to convert
> the iterator to a list first -- it may be that the number of items in
> the data stream is too large to fit into memory all at once, but even
> if it is small, it means you're now walking the stream three times when
> one would do.
>
> To my mind, minmax() is as obvious and as useful a built-in as divmod(),
> but if there is resistance to making such a function a built-in,
> perhaps it could go into itertools. (I would prefer it to keep the same
> signature as min() and max(), namely that it will take either a single
> iterable argument or multiple arguments.)
>
> I've experimented with minmax() myself. Not surprisingly, the
> performance of a pure Python version doesn't even come close to the
> built-ins.
>
> I'm +1 on the idea.
>
> Presumably follow-ups should go to python-ideas.

The discussion which followed this up has digressed quite a bit, but
I'd like to mention that I'm +1 on having an efficient minmax()
function available.

- Tal