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

[James J. Besemer]

Alex Martelli wrote:

> On Thursday 02 May 2002 03:25 pm, James J. Besemer wrote:
>         ...
> > > >> Since seq.index(max(seq)) is most concise, fastest, and quite clear,
>
> > (a) I thought I was using the term consistently with others in posts
> > earlier, when we were talking about map() and filter().
>
> Those ARE higher-order functions, you know.

You'll have to define the term for me then.

I haven't studied FP for a long time.  I distinctly recall a lecture by John
Backus years ago that later was published in CACM (Turing award paper, IIRC).  We
all went to a lecture by the inventor of Fortran to see what he had been up to in
the time since and the answer was he was developing a Functional Programming
language called FP, faintly remniscant of APL.  It was the first I ever heard of
the concept.

Now it may have a different name now but as I recall it, he had this certain FP
form and then walked us through a way of determining the "derivitive" of that
algorithm.  I don't recall what "derivative" meant in that domain but to me
"higher order" for FP is analogous to THAT kind of manipulation with differential
equations (which in practice has little to do with day to day programming
practices).

> Ah, APL, the ultimate functional programming language!  Sorry, but that
> FAQ's response seems rather inapplicable to me here.

That FAQ didn't mention APL, though now that you mention it, I in my ignorance
would clasify it as a functional programming language.

> Just because
> you're calling an ordinary function or two (even on vectors) doesn't mean
> your overall style "emphasizes the evaluation of expressions, rather than
> the execution of commands".  Were I do define FP, I'd focus on 'immutable
> data' (or 'single assignment' as being roughly equivalent).  Thus ruling APL
> out because, while STRONGLY expression-oriented (and vector, too!),
> its typical expressions most often include the <- (leftarrow) operator which,
> surprise surprise, assigns data.

(a) in APL functions, assignment was mostly used as a short hand for eliminating
common sub-expressions, something you can't otherwise easily do in a textual
representation.  Also, wasn't assignment used to designate the return result from
a function?  I admit, howver, they did technically constitute statements and there
even was a goto if I am not mistaken.

(b) perhaps assignment can be eliminated in some kind of "pure" FP (like in "pure"
Scheme).  BUt in practice programmers need to put the results somewhere.   Seems
FP could apply to your "overall style" and still use assignment.

But you're the expert.

> You may choose to define "basic FP tasks" as being those which require
> neither data mutation or name rebinding, nor higher-order functions.  Not
> a very large set, to be sure, but still it would apply to e.g. all pure string
> manipulations in Python -- still, IMHO, too wide a set for usefully sharp
> definition.

I wasn't thinking of them but, yes, I'd lump all the string functions (ones that
map strings onto strings) into the FP bin.

Regards

--jb

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