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

Alex Martelli aleax at aleax.it
Thu May 2 05:54:24 EDT 2002


James J. Besemer wrote:
        ...
> So some long standing coding instincts no longer apply.  "Everything you
> know is wrong."

One thing everybody (who knows anything) knows, which is still completely
right, is that programmers' instincts are more often wrong when guessing
about performance issues than about any other topic (well, perhaps timing
and deadline for software completion and delivery are still in contention).

I think I was first exposed to this unsettling but by now universally
accepted truth by a side note in Hartmann's report on his Concurrent
Pascal compiler, back when I was still in University, a full quarter of
a century ago.  As I recall, after heroic and growingly more complex
attempts at optimization, they finally MEASURED what the bottleneck
was -- and it turned out to be something utterly trivial, such as the
loop that trimmed the trailing blanks off the punched-card images for
each line of the input.  That made an impression...!  Duly reinforced
a few short years later by Jon Bentley's impressive "Writing Efficient
Programs" (Prentice-Hall).

"Don't guess, MEASURE" was of course drilled into us throughout engineering
school -- but those professors who were also experienced engineers "out
in the field" did make it clear that, once one's instincts are well honed,
in MOST (mature) fields of engineering, they may be preferable to any
computation or measurement -- when the measurement or computation tell
you one thing and your instincts tell you another, you start looking for
where did the computation or measurement go wrong.  There are exceptions,
we were told, such as certain complicated turbulent flows in aerodynamics
(and to a lesser extent hydrodynamics), where instincts are misleading and
one learns to rely on modeling, simulation, measurement, etc.

Performance of computer systems is definitely one of those "exceptions"
fields of engineering.  Things haven't changed much in that regard in the
20 years since Bentley's book, or the 25+ years since Hartmann's.  You
may use (well-honed) instincts as a design guide, but in the end, IF the
performance matters, you always need to measure.  Fortunately, it's a
far easier task than in some other fields of engineering:-).


>> 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.

Functional Programming is indeed an elegant paradigm, but it's not the
one being used here -- no higher-order functions, etc.  Or maybe you
mean something else by FP (Floating Point?  naah...).

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

Fortunately not.  Only for big-O issues (and none of these approaches
is anything else than O(N), obviously big-O-optimal here) is it a
worry you can almost never brush aside.  Fortunately, big-O issues
CAN often be worked out from first principles (if you have the right
starting data) -- so, whenever a constant factor of, say, 100% either
way does not matter (i.e., by far in the largest part of the code
one writes), one is free to go for simplicity and elegance:-).


Alex




More information about the Python-list mailing list