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

[James J. Besemer]

Alex Martelli wrote:

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

This is something I too learned long ago, in the 70s.  There was a period
before that long ago where I would spend a lot of time optimizing everything.
Then I learned the anecdote about (as I heard it) the bottleneck being in some
low level library routine.  Back in the olden days, some optimizations were
necessary simply to fit into memory or to finish in a tolerable time.  Soon
machines were big and fast enough that that was not much of a problem.  (Of
course the advent of microprocessors set us back again for a while.)

Still, I tended to code straight-forward code and only work on optimizations
that were absolutely necessary.  Lately I sometimes code things up expecting
them to be a problem and it almost never is.  Machines are simply so fast that
performance is seldom an issue.  There's an additional bonus, as highly
optimized code tends to be more prone to contain bugs and to be more difficult
to get right.  So, the simpler, straight-forward code is much quicker to get
running.

HOWEVER, in designing good algorithms, I still tend unconsciously to apply the
"order" statistics analysis you discussed in your last post.  They still can
have a direct bearing on performance, even in Python.

My flaw in the previous case was in equating the performance of an order N loop
with an order N built-in, forgetting that it's apples and oranges.  It was
doubly stupid of me because I had run my own performance measurements just the
day before.  And the for loop was slower by far than everything except List
Comprehensions.

> "Don't guess, MEASURE" [... and many other good points... ]

> >> Since seq.index(max(seq)) is most concise, fastest, and quite clear,
>
> 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...).

EEEEKKKK!!!!  SARCASM!!!!   RUN AWAY!! RUN AWAY!!  ;o)

Seriously, I respectfully and humbly beg to differ...

(a) I thought I was using the term consistently with others in posts earlier,
when we were talking about map() and filter().

(b) To me FP fundamentally is actually little more than tending towards
expressions instead of statements.  And this is consistent with the
comp.lang.FP Faq

    (http://www.cs.nott.ac.uk/~gmh//faq.html)

Typically for it to be FP the operands are not scalars but vectors or more
complex objects that may be thought to "flow" from one operator to the next.
Higher order functions are included in the broader topic but they're not
necessary to perform basic FP tasks.

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

Yup.

Regards

--jb

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