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 -- https://mail.python.org/mailman/listinfo/python-list
