Newbie: finding the key/index of the min/max element

James J. Besemer jb at cascade-sys.com
Wed May 1 19:31:54 EDT 2002


> James J. Besemer wrote:
>
>
> > Stick with the Loop, my son.  Sometimes a cigar is just a cigar.
> >       ...
> > Then too, for small lists performance need not be a consideration.
>
> Alex Martelli wrote:
>
> Right, but efficiency generally needs _measuring_.  Guesses are no good.
>
> [ many stats]

> So, performance doesn't really matter much -- but in as much as it does,
> the "noloop" approach wins hands down, taking 1/2 to 1/3 the time of
> the "obvious" loop (forget the zip approach, clearly).

In retrospect, it's obvious that the for loop involves lots more interpretive
code, while the dreaded FP form better leverages efficient C runtime routines
inside the interpreter.

So some long standing coding instincts no longer apply.  "Everything you know
is wrong."

> Since seq.index(max(seq)) is most concise, fastest, and quite clear,
> I think it qualifies for "the one obvious way to do it" in this case.
> Pity it doesn't work for mappings, only for sequences...

I was tempted to question whether this solution also qualifies for "elegance"
but I don't see how I can.  The FP paradigm is pretty compelling.

Your stats do seem to support my inclination to avoid creating auxilliary
structures, as that solutions was by far the slowest, in some cases by
several orders of magnitude.  So not everything I know is wrong.  Order
statistics and other traditional analysis can apply so long as you only apply
them at the source statement level.

And we're agreed that a lot of the time performance is not a consideration.

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com







More information about the Python-list mailing list