how to get the ordinal number in list

[Rustom Mody]

On Tuesday, August 12, 2014 11:10:48 PM UTC+5:30, Neil D. Cerutti wrote:
> On 8/10/2014 2:14 PM, Roy Smith wrote:
> >   Rustom Mody  wrote:
> >>>>> 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.
> >> 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"
> >> [...]
> >> All the above are clearer than loops+assignments and can be
> >> taught before them
> > I disagree.  For a beginner, you want to be able to break things down
> > into individual steps and examine the result at each point.  If you do:
> >>>>> l= [6,2,9,12,1,4]
> >>>>> l2 = sorted(l,reverse=True)
> > you have the advantage that you can stop after creating l2 and print it
> > out.  The student can see that it has indeed been sorted.  With the
> > chained operations, you have to build a mental image of an anonymous,
> > temporary list, and then perform the slicing operation on that.  Sure,
> > it's the way you or I would write it in production code, but for a
> > beginner, breaking it down into smaller pieces makes it easier to
> > understand.
> >>>>> l2[:5]

> Yes, and that teaching technique is supported by research.


Yes and I as said to Roy I dont see any disagreement at least on this account.



> Beginners are particularly poor, in relation to experts, at noticing the 
> applicability of idea, and at combining ideas together. Breaking things 
> into component parts has multiple benefits:

> 1. The applicability of individual ideas becomes obvious. It's one thing 
> to know about [].sort, and another thing to know when it's appropriate 
> to sort something.

> 2. The expert specifically shows how and why the ideas are combined. 
> This helps build the connection for the beginner, whose knowledge is not 
> stored as an expert stores it; i.e, in broad categories with multiple 
> connections; but as disorganized data with very few connections.

Nice!

And how do we lead the beginners towards expertise?
In a way functional programming is to programming creativity 
what lego is to children's spatial creativity.

Specifically there are a bunch of pieces that need to fit:

1. Functional Programming: Nothing more than composing functions
   [Maybe a bit simplistic but not unrealistic a defn]
2. Trying this out at the interpreter
3. Introspectable objects

Some things follow from this:

For the lego-game of playing with functions at the REPL to work and be
pleasant and rewarding:

1. functions should be non side-effecting; else same trials giving different
answers adds more confusion than understanding
2. They should be non-printing else:

def foo(x): return x+1
def bar(x): print x+1

look similar when trivially tried but compositionally are utterly different

In effect a printing function breaks the lego bricks

[The P in the REPL is DRY enough that it does not usually need to be
repeated all over]

3. Abstractions (class instances) should be avoided in favor of
concrete data (lists, dicts, scalars) because they add undue mess at little
comprehension advantage. eg take the example of a regex match. It
returns some object and then we have to scratch our heads wondering
whats in the magic box. If instead of match, we use findall, the data
is manifest and obvious.


> http://www.amazon.com/How-Learning-Works-Research-Based-Principles/dp/0470484101

> I bought the book based on a recommendation from SciPy talk, and it's 
> really great. As an autodidact, it'll help me teach *myself* better, too.

Looks interesting. Will take a look.