how to get the ordinal number in list

[Steven D'Aprano]

Rustom Mody wrote:

> On Saturday, August 9, 2014 9:04:22 PM UTC+5:30, Roy Smith 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.
> 
> makes perfect sense... under one assumption: viz.
> The 'first steps' to becoming a programmer are necessarily imperative
> steps. So much so that programming is usually *defined* as imperative
> programming. This usually goes thus:

"Necessarily"? Well, that's possibly a bit strong, but I think it is
reasonable to say that the first steps to becoming a programmer are
*preferably* imperative, because the real world is imperative. If you want
to make a coffee, you:

- get a cup
- put instant coffee in the cup
- put sugar in the cup
- boil water
- pour boiling water into the cup
- stir
- add milk

not:

- call an abstract make_coffee() function.


> - CS is defined as the science of algorithms (or algorithmics)

Yes, but algorithms can be either concrete ("put the kettle on the stove and
light the gas"), intermediate ("bring the water to the boil at 100°C"), or
fully abstract ("f(Temperature(water)) = lambda: 100°C", or something like
that). So CS can and does envelop both imperative and functional
programming. They just don't typically teach functional programming to
beginners.



> - Programming (in the layman sense: python, java, C etc) is just about
> converting these 'abstract algorithms' into executable code
> - And an algorithm?   An algorithm is an effective method expressed as a
> finite list[1] of well-defined instructions[2] for calculating a function.
> quoting http://en.wikipedia.org/wiki/Algorithm
> 
> 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.

Nobody says that you do. You're attacking a strawman.


> IOW the 'calculating a function' is primary and the 'effective steps'
> is secondary and traditional programming pedagogy gets this order wrong.

"Calculating a function" is *incredibly* abstract, and quite hard to
consider. If you think it isn't, then you're probably focused on a subset
of problems that involve transformations which are trivially modelled by
mathematical functions.


> What do I need to know to use sort? Nothing? Not so. I should be able to
> distinguish a sorted list from an unsorted one.  This is primary.
> Getting from one to the other -- the how -- is secondary.

And how do you distinguish sorted list from an unsorted list, using
functional styles? You're not allowed to just propose a magic "is_sorted()"
function, any more than you're allowed to propose a magic "do whatever I
want" function. (The whole point of CS is to learn how to program, not to
just assume the program you want already exists.) Nor is it sufficient to
define it this way:

def is_sorted(alist):
    return alist == sorted(alist)

since that assumes that sorted is correct. Consider this definition of
sorted:

def sorted(alist):
    return alist

Now, the naturally intuitive way to determine whether something is sorted is
imperative: you start at one end of the list and loop over pairs of items.
If every item is >= to the previous item, the list is sorted. Now, of
course we both know that we can turn that into a functional approach using
reduce(), but if you can find one person in a hundred -- hell, even one
person in a thousand -- who will intuitively come up with that approach in
preference to the imperative style without being coached, I'll buy you a
coffee or soft drink of your choice.

Even Carl Gauss started off reasoning imperatively, and he was a natural
mathematics genius.

Learning programming is hard enough without trying to do it floating up in
the stratosphere breathing vacuum. Abstractions are *hard*, and the
functional approach is an abstraction.


[...]
> As a more demonstrative example of the above (abstract) talk, in the 90s
> I used to teach a first course in programming using a predecessor of
> haskell (gofer -- gofer stands for GOod For Equational Reasoning).

Aimed at what age and experience of student? There's a big difference
between aiming a course at mathematics post-grads, or at 12 year olds who
are still a bit fuzzy about the whole "what's a function?" thing.

What percentage of students passed?

> By the end of the course students could
> - handle data structures like generic n-ary trees, graphs etc
> - write toy interpreters, compilers, semantic functions
> - combinatorial enumerators corresponding to various types
> of combinatorial functions like ⁿCr ⁿPr Catalan numbers
> 
> All WITHOUT a single assignment statement
> [very easy to accomplish since the language has no assignment statement
> [:-) ]
> 
> and more important (and germane to this thread) NO PRINT statement.

Hmmm. With no print, how could they tell whether their program was correct?
By writing to a file? But that's just a generalised print.

Wait... I get it... you have a print, it's just a function, not a statement.
Am I close?


> Instead if we treated the python:
> 
> [x**2 for x in range(10)]
> 
> as an executable version for the standard set-theory expression:
> 
> {x² | x ∈ [0..10) }

Apart from a difference of notation, the way I learned list comprehensions
was by learning the correspondence to "set builder notation", but then I
have a maths degree and many years of practice at using that notation. The
average beginner may never have seen set builder notation, or forgotten it
if they have.


-- 
Steven