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

[Zac Burns]

This could be generalized and placed into itertools if we create a function
(say, apply for lack of a better name at the moment) that takes in an
iterable and creates new iterables that yield each from the original
(avoiding the need for a list) holding only one in memory. Then you could
pass the whatever function you wanted to run the iterables over an get the
result back in a tuple.

Eg:

itertools.apply(iterable, min, max) ~= (min(iterable), max(iterable))

This class that creates 'associated iterables' from an original iterable
where each new iterable has to be iterated over at the same time might also
be useful in other contexts and could be added to itertools as well.


Unfortunately this solution seems incompatable with the implementations with
for loops in min and max (EG: How do you switch functions at the right
time?) So it might take some tweaking.

--
Zachary Burns
(407)590-4814
Aim - Zac256FL



On Sun, Oct 10, 2010 at 4:17 PM, Steven D'Aprano <steve at pearwood.info>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.
>
>
>
> --
> Steven D'Aprano
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20101010/ea2be184/attachment.html>