how to get the ordinal number in list

[Steven D'Aprano]

Rustom Mody wrote:

> On Sunday, August 10, 2014 10:40:21 PM UTC+5:30, Roy Smith wrote:
>>  Rustom Mody  wrote:
> 
>> > > They haven't figured out yet that the
>> > > first step to solving a problem is to decide what algorithms you're
>> > > going to use, and only then can you start translating that into code.
>> > > They need to be led in small steps towards basic knowledge.
>> > [...]
>> > In my view this is starting from the wrong end.
>> > I do not need to know which kind of adder the hardware is implementing
>> > to use +, which sorting algorithm to use sort, etc.
> 
>> Well, no, but if the problem is, "Find the 5 largest numbers in a list",
>> you might start solving the problem by thinking, "OK, first I'm going to
>> sort the list into descending order, then I'm going to take the first
>> five items from that"(*)  Only then would you get down to "OK, how do I
>> sort a list of numbers in this language", and "OK, how do I select the
>> first five items from a list in this language".  That's what I mean by
>> first you come up with an algorithm, then you implement it in code.
> 
>>>> l= [6,2,9,12,1,4]
>>>> sorted(l,reverse=True)[:5]
> [12, 9, 6, 4, 2]
> 
> No need to know how sorted works nor [:5]
> 
> Now you (or Steven) can call it abstract.

It *is* an abstraction. You are abstracting away the details of the real
computer implementation into an abstraction of a pure mathematical
function, and that's fine. As programmers, that's what we do. But
abstractions leak, and someday someone is going to ask "Why does it take 45
minutes to find the five largest values of my list?", and if you persist in
insisting that sorted() is a pure mathematical function you will have no
clue on how to even begin solving this, except perhaps to deny that it
matters.

But because abstractions leak, and I know that the concrete implementation
is more fundamental than the abstraction, I can answer the question:
perhaps their system uses bubblesort instead of Timsort. Or perhaps their
list has a hundred thousand billion items. Or, if we're talking about
Python, perhaps the __lt__ method of the items is horribly inefficient. To
those who insist that the abstraction is all that matters, these concrete
factors are irrelevant, but in practice they can be critical.

The real question is, as educators, should we teach the abstraction or a
concrete implementation first? In actuality we do both. As a first year
computer science student learning Pascal, I was taught to add numbers using
+ without caring about the details of the hardware adder, although I was
taught to care about the abstractions "Integer" and "Real" leaking (i.e.
the possibility of overflow). On the other hand, I was taught to write my
own sort function, partly because Pascal doesn't have one, but mostly
because *learning how to program* was the whole point of the class and the
people teaching the course decided that sort algorithms was the right level
of complexity for their intended audience.

You did the same thing in your own course, the only difference being you
accepted a different set of primitive functions. But ultimately you have to
introduce *some* amount of concreteness, at some level, otherwise we're
just engaged in mental masturbation:

Q: "Write a function to calculate the nth Catalan number."
A: "Assume that a function Catalan(n) exists and calculates the nth Catalan
number. Then the solution is Catalan."


> And yet its
> 1. Actual running code in the interpreter
> 2. Its as close as one can get to a literal translation of your
>    "Find the 5 largest numbers in a list"
> 
> Yeah the reverse=True is a fly in the ointment.

Why? It's just syntax. In the abstract, there is no difference between
sorted_descending(alist) and sorted(alist, reverse=True), they're just
different ways of spelling the same thing.



-- 
Steven