Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75925 > unrolled thread

Re: how to get the ordinal number in list

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: how to get the ordinal number in list luofeiyu <elearn2014@gmail.com> - 2014-08-09 10:35 -0700
    Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-09 13:06 +1000
      Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-08 20:48 -0700
        Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-09 11:34 -0400
          Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-10 09:43 +1000
          Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 09:28 -0700
            Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 13:10 -0400
              Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 10:34 -0700
                Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 14:14 -0400
                  Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 11:26 -0700
                    Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 05:03 +1000
                      Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-10 22:14 +0300
                        Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 05:20 +1000
                      Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 22:23 -0700
                        Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 15:46 +1000
                          Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 23:22 -0700
                            Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 08:55 +0000
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:15 +1000
                            Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 12:35 +0300
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:51 +1000
                                Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 13:46 +0300
                                  Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 21:06 +1000
                        Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 09:44 +0000
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:53 +1000
                            Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 21:30 +1000
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 20:07 +1000
                            Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 10:47 +1000
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 11:31 +1000
                                Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-12 21:45 -0400
                                  Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 12:06 +1000
                        Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-11 07:55 -0400
                          Re: how to get the ordinal number in list Tim Chase <python.list@tim.thechases.com> - 2014-08-11 07:30 -0500
                            Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 15:41 +0300
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 22:53 +1000
                          Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 14:57 +0100
                    Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-10 21:32 +0100
                      Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 18:01 -0400
                        Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 08:43 +1000
                        Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 20:35 -0700
                    Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 12:04 +1000
                      Re: how to get the ordinal number in list Robert Kern <robert.kern@gmail.com> - 2014-08-11 12:56 +0100
                        Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-11 05:11 -0700
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 22:45 +1000
                          Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 15:01 +0100
                        Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-11 12:30 +0000
                          Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 15:41 +0300
                          Re: how to get the ordinal number in list Robin Becker <robin@reportlab.com> - 2014-08-11 15:32 +0100
                          Re: how to get the ordinal number in list Terry Reedy <tjreedy@udel.edu> - 2014-08-11 18:01 -0400
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-12 09:27 +1000
                            Re: how to get the ordinal number in list wxjmfauth@gmail.com - 2014-08-12 00:21 -0700
                              Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-12 10:40 +0000
                                Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-12 23:39 +1000
                                  Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-12 18:45 +0000
                                    Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-12 20:16 +0100
                  Re: how to get the ordinal number in list "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-12 13:40 -0400
                    Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-12 11:20 -0700
                      Re: how to get the ordinal number in list "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-12 15:29 -0400
                        Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-12 20:49 -0700
                  Re: how to get the ordinal number in list Terry Reedy <tjreedy@udel.edu> - 2014-08-12 18:01 -0400
                Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 13:00 +1000
                  Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 21:29 -0700
                    Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 10:28 +0000
                      Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-11 04:49 -0700
                        Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 12:11 +1000
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 12:18 +1000
                          Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 13:11 +1000
            Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 03:17 +1000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#76050

On 2014-08-11 03:04, Steven D'Aprano wrote:
> Rustom Mody wrote:
>
>> Its when we have variables that are assigned in multiple places that
>> we start seeing mathematical abominations like
>> x = x+1
>
> That's not a mathematical abomination. It's a perfectly reasonable
> mathematical equation, one with no solutions since the line f(x) = x and
> the line f(x) = x+1 are parallel.
>
> But what does this have to do with programming? Programming *is not*
> mathematics, and x = x+1 has a different meaning in programming than in
> mathematics. Perhaps it would help if we wrote it using mathematical
> notation? Using [x] for subscripts:
>
> x[n+1] = x[n] + 1
>
> we have a perfectly good mathematical recursive definition. All it needs is
> an initial value x[0] and we're good to go.

Or a different operator for assignment (to distinguish it more clearly from 
equality, which it isn't).

   x <- x + 1
   x := x + 1

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#76051

Having it both ways aren't you?

On the one hand you say

On Monday, August 11, 2014 3:21:35 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa wrote:
> > Python is a formal language with a well-defined syntax and reasonably
> > well-understood semantics. That's all that matters. Any resemblance to
> > the much more ad-hoc syntax of classical mathematics is almost
> > coincidental.

> Well, it's a bit more than coincidence. It's the ELIZA effect:

> http://www.catb.org/jargon/html/E/ELIZA-effect.html

Which describes the Eliza effect as:
The tendency of humans to attach associations to terms from prior experience.

Then you continue:

> Using notations that some people will be familiar with is better than
> constructing brand new notations from scratch, even if not everyone
> can gain that benefit. (Which is an argument in favour of Python's
> percent-formatting of strings; there are plenty of people out there
> who'll instantly understand that %d will plop in an integer and %s a
> string - even some non-programmers know that notation, as it's found
> in config files, translation data, etc, etc.)

So evidently using notations in the ways they are conventionally used
is a good thing.

But then when it comes to Steven supporting the violation 500 years* of
math conventional usage of '=':

On Monday, August 11, 2014 2:45:48 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 6:55 PM, Steven D'Aprano wrote:
> > On Sun, 10 Aug 2014 23:22:45 -0700, Rustom Mody wrote:
> >> You think that the '=' sign not standing for math equality is ok.
> >> How come?
> > For the same reason that in the following:
> > [c.upper() for c in some_string if 'a' < c < 'x']
> > having the c symbol not stand for the speed of light is okay. Likewise,
> > in the sentence "I went to the park today", the symbol I doesn't mean the
> > element iodine. Symbols are context-dependent: the x in one equation is
> > not necessarily the same x in another equation, and the symbol = in one
> > context does not necessarily have the same meaning as in another context.

you are strongly approving.

You really need to decide which side you are on!

eg Marko disagrees but is fairly consistent: "Whether I like it or not, whether its
conventional or not... Quite irrelevant. Its formally defined. I follow the
definition. [Browser tabs stay open in case I slip]"

But you seem to be hopping between:

Its easy, its natural and thats why its so

and

Its the way it is... Take it or leave it

* Robert Recorde invented the '=' and introduced algebra to England in 1557
http://en.wikipedia.org/wiki/Robert_Recorde#Publications

[toc] | [prev] | [next] | [standalone]

#76056

On Mon, Aug 11, 2014 at 10:11 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> So evidently using notations in the ways they are conventionally used
> is a good thing.
>
> But then when it comes to Steven supporting the violation 500 years* of
> math conventional usage of '=':

Yep. It's not a violation; it's a modification. Since algebra has no
concept of chronology and programming does, some notation must be
found which captures this concept. Try explaining complex numbers to
someone who has only ever used real numbers, and explain why you
violate however-many centuries of conventional usage wherein letters
are used for variables, but now you pick one of them and make it a
constant. It's an abomination! This "complex" stuff is so utterly
wrong compared to "real mathematics", and how dare you even support
using symbols the same way in both of them!

The double horizontal line is associated with equality. Assignment
states that the LHS after this point is equal to the RHS before this
point, which is a chronologically modified form of enforced equality.
It makes good sense to use the double horizontal line for equality.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76061

On 11/08/2014 13:11, Rustom Mody wrote:
>
> But then when it comes to Steven supporting the violation 500 years* of
> math conventional usage of '=':
>

I have no interest in the maths convention (see, you don't even know the 
original, correct English, math indeed).  Of far more importance in the 
real world is the Irish navvy convention.  Are there any such people 
lurking here who can give us the required insight?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#76052

On Mon, 11 Aug 2014 12:56:59 +0100, Robert Kern wrote:

> On 2014-08-11 03:04, Steven D'Aprano wrote:
>> Rustom Mody wrote:
>>
>>> Its when we have variables that are assigned in multiple places that
>>> we start seeing mathematical abominations like x = x+1
>>
>> That's not a mathematical abomination. It's a perfectly reasonable
>> mathematical equation, one with no solutions since the line f(x) = x
>> and the line f(x) = x+1 are parallel.
>>
>> But what does this have to do with programming? Programming *is not*
>> mathematics, and x = x+1 has a different meaning in programming than in
>> mathematics. Perhaps it would help if we wrote it using mathematical
>> notation? Using [x] for subscripts:
>>
>> x[n+1] = x[n] + 1
>>
>> we have a perfectly good mathematical recursive definition. All it
>> needs is an initial value x[0] and we're good to go.
> 
> Or a different operator for assignment (to distinguish it more clearly
> from equality, which it isn't).
> 
>    x <- x + 1 x := x + 1

It already is a different operator from equality which is ==

perhaps it would have been better if the behaviour of these two operators 
were reversed (= for equality & == for assignment) but i suspect that 
Idea if even considered was quickly discarded as it would cause major 
confusion to programmers who work with multiple languages  


-- 
Meskimen's Law:
	There's never time to do it right, but there's always time to
	do it over.

[toc] | [prev] | [next] | [standalone]

#76054

alister <alister.nospam.ware@ntlworld.com>:

> It already is a different operator from equality which is ==
>
> perhaps it would have been better if the behaviour of these two
> operators were reversed (= for equality & == for assignment) but i
> suspect that Idea if even considered was quickly discarded as it would
> cause major confusion to programmers who work with multiple languages

Blame it on FORTRAN:

   X = X + 1
   IF (X .EQ. 100) GOTO 999

BASIC took a no-nonsense approach:

   5 LET S = 0 
   10 MAT INPUT V 
   20 LET N = NUM 
   30 IF N = 0 THEN 99 
   40 FOR I = 1 TO N 
   45 LET S = S + V(I) 
   50 NEXT I 
   60 PRINT S/N 
   70 GO TO 5 
   99 END

   (<URL: http://en.wikipedia.org/wiki/BASIC#Examples>)


Marko

[toc] | [prev] | [next] | [standalone]

#76063

On 11/08/2014 13:30, alister wrote:
> It already is a different operator from equality which is ==
>
> perhaps it would have been better if the behaviour of these two operators
> were reversed (= for equality & == for assignment) but i suspect that
> Idea if even considered was quickly discarded as it would cause major
> confusion to programmers who work with multiple languages


Of course Python can be even more confusing so that for example

 >>> class NeverEqual(int):
... 	def __new__(cls,v):
... 		self = int.__new__(cls,v)
... 		return self
... 	def __eq__(self,other):
... 		return False
...
 >>> a=NeverEqual(1)
 >>> a
1
 >>> a==1
False
 >>> a==a
False
 >>> not (a != a)
True
 >>> a!=a
False
 >>>

so I think that assignment doesn't always make things equal even chronologically.
-- 
Robin Becker

[toc] | [prev] | [next] | [standalone]

#76079

> On 11/08/2014 13:30, alister wrote:
>> It already is a different operator from equality which is ==

Mathematicians use '=' for name binding all the time, with and without 
'let':
   Let u = x + y, v = x - y. Then ... .
However, name binding itself is a mental operation, not a mathematical one.

Mathematicians sometimes differentiate conditionally true expressions 
from necessarily true expressions (tautologies, 'identically true') by 
using triple bars for the latter.  In algebra, (a+b)(a-b) <triple bar 
equal> a*a-b*b.  I think the sense of the extra bar is 'really equal, 
not just contingently equal).

Mathematicians sometimes use ':=' for definitions and sometimes decorate 
'=' in various other ways. Unicode has most of them. So mathematicians 
do not always use plain '=' for various ideas of sameness.

>> perhaps it would have been better if the behaviour of these two operators
>> were reversed (= for equality & == for assignment) but i suspect that
>> Idea if even considered was quickly discarded as it would cause major
>> confusion to programmers who work with multiple languages.

Given that assignment occurs more often than equality testing, it makes 
sense to use the shorter coding for assignment.  This principle operates 
in natural language (English at least) and in various codings from Morse 
to Huffman.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#76087

On Tue, Aug 12, 2014 at 12:32 AM, Robin Becker <robin@reportlab.com> wrote:
> Of course Python can be even more confusing so that for example
>
>>>> class NeverEqual(int):
> ...     def __new__(cls,v):
> ...             self = int.__new__(cls,v)
> ...             return self
> ...     def __eq__(self,other):
> ...             return False
> ...
>>>> a=NeverEqual(1)
>>>> a
> 1
>>>> a==1
> False
>>>> a==a
> False
>>>> not (a != a)
> True
>>>> a!=a
> False
>>>>
>
> so I think that assignment doesn't always make things equal even
> chronologically.

Sure, but at this point you're fiddling with the definition of
equality, and Python has never stopped you from shooting yourself in
the foot :) There are less contrived examples, too, like those
involving floating-point round-off, which basically prove that
Python's equality comparison is not the same as mathematical equality;
but that doesn't stop people from comprehending that "1 + 3 == 2 + 2"
in Python based on their knowledge of mathematics.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76104

Math:

Try to formalize with mathematics the Flexible String Representation.
You should quickly realize, it is a logical mathematical absurdity.
Unbelievable.

jmf

[toc] | [prev] | [next] | [standalone]

#76109

On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:

> Math:
> 
> Try to formalize with mathematics the Flexible String Representation.
> You should quickly realize, it is a logical mathematical absurdity.
> Unbelievable.
> 
> jmf

Mathematicians work with numbers (Algebra is a abstraction of numerical 
concepts) strings are concerned with characters (Arabic numerals are just 
characters commonly used to represent numbers )
therefore even trying to rationalise any string representation with 
mathematics is a logical absurdity in itself.




-- 
Someone on IRC was very sad about the uptime of his machine wrapping
from 497 days to 0.
	-- linux-kernel

[toc] | [prev] | [next] | [standalone]

#76112

On Tue, Aug 12, 2014 at 8:40 PM, alister
<alister.nospam.ware@ntlworld.com> wrote:
> On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
> [ chomp ]
>
> Mathematicians work with numbers (Algebra is a abstraction of numerical
> concepts) strings are concerned with characters (Arabic numerals are just
> characters commonly used to represent numbers )
> therefore even trying to rationalise any string representation with
> mathematics is a logical absurdity in itself.

Don't bother responding to jmf; he doesn't listen. Also, his posts
don't survive the jump to python-list, so we see them only when
someone quotes him like that... as far as I'm concerned, his posts are
now on par with those trying to sell us solution manuals or herbal
remedies.

ChrisA

[toc] | [prev] | [next] | [standalone]

#76133

On Tue, 12 Aug 2014 23:39:42 +1000, Chris Angelico wrote:

> On Tue, Aug 12, 2014 at 8:40 PM, alister
> <alister.nospam.ware@ntlworld.com> wrote:
>> On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
>> [ chomp ]
>>
>> Mathematicians work with numbers (Algebra is a abstraction of numerical
>> concepts) strings are concerned with characters (Arabic numerals are
>> just characters commonly used to represent numbers )
>> therefore even trying to rationalise any string representation with
>> mathematics is a logical absurdity in itself.
> 
> Don't bother responding to jmf; he doesn't listen. Also, his posts don't
> survive the jump to python-list, so we see them only when someone quotes
> him like that... as far as I'm concerned, his posts are now on par with
> those trying to sell us solution manuals or herbal remedies.
> 
> ChrisA

As you don't see them unless someone replies I will make sure I don't 
reply to any more of his posts.

I would not want to inflict this nonsense on someone who would otherwise 
be spared.


-- 
You will lose an important tape file.

[toc] | [prev] | [next] | [standalone]

#76144

On 12/08/2014 19:45, alister wrote:
> On Tue, 12 Aug 2014 23:39:42 +1000, Chris Angelico wrote:
>
>> On Tue, Aug 12, 2014 at 8:40 PM, alister
>> <alister.nospam.ware@ntlworld.com> wrote:
>>> On Tue, 12 Aug 2014 00:21:28 -0700, wxjmfauth wrote:
>>> [ chomp ]
>>>
>>> Mathematicians work with numbers (Algebra is a abstraction of numerical
>>> concepts) strings are concerned with characters (Arabic numerals are
>>> just characters commonly used to represent numbers )
>>> therefore even trying to rationalise any string representation with
>>> mathematics is a logical absurdity in itself.
>>
>> Don't bother responding to jmf; he doesn't listen. Also, his posts don't
>> survive the jump to python-list, so we see them only when someone quotes
>> him like that... as far as I'm concerned, his posts are now on par with
>> those trying to sell us solution manuals or herbal remedies.
>>
>> ChrisA
>
> As you don't see them unless someone replies I will make sure I don't
> reply to any more of his posts.
>
> I would not want to inflict this nonsense on someone who would otherwise
> be spared.
>

Thank you, as it saves me from once again losing it in public when his 
latest incarnation of complete dross appears.  Two years he's been at 
it, I wonder how he manages to avoid "Sent to jail. Do not pass Go. Do 
not collect £200" or where he gets his supply of "Get out of jail free" 
cards from?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#76125

On 8/10/2014 2:14 PM, Roy Smith wrote:
> In article <154cc342-7f85-4d16-b636-a1a953913c98@googlegroups.com>,
>   Rustom Mody <rustompmody@gmail.com> 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.

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.

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.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#76128

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.

[toc] | [prev] | [next] | [standalone]

#76146

On 8/12/2014 2:20 PM, Rustom Mody wrote:
> On Tuesday, August 12, 2014 11:10:48 PM UTC+5:30, Neil D. Cerutti wrote:
>> 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

Functional programming could be particularly hard to teach since it is 
generally made up of numerous small units of work combined in a complex 
way. This is precisely the formula for something that beginners will 
find extremely challenging.

When functional programming is dumbed down enough for a beginner to be 
able to grok it, the programming problems start to look really lame. It 
needn't be that way, of course, but it takes a good deal of creativity 
on the part of the instructor. If Factorial doesn't turn you on, you 
might be screwed. ;)

> 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

That may be so, but printing stuff to the screen is very natural to 
people. I've downloaded Haskell a few times, but the knowledge that 
getting input and writing output requires something mysterious called 
gonads just frightens me.

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

A good REPL does help a lot, though.

> 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.

I'm with you on regex: match objects suck. That and escaping.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#76168

On Wednesday, August 13, 2014 12:59:35 AM UTC+5:30, Neil D. Cerutti wrote:

> > 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

> That may be so, but printing stuff to the screen is very natural to 
> people. I've downloaded Haskell a few times, but the knowledge that 
> getting input and writing output requires something mysterious called 
> gonads just frightens me.

I thought they were quite common <wink>

But yes...

- Monads in Haskell
- Pointers in C
- Inheritance in Java/Python

all suffer the same problem -- glorification of the failure-mode.

When one uses pointers, especially non-trivial pointer arithmetic in C,
one is essentially blasting a hole in the floor of the hi-level facade
of C and working at machine level.

Inheritance produces coupling whereas the whole intent of modularity is to 
avoid coupling.

Likewise Monads are for imperative programming in Haskell.
Maybe better to just use an imperative language?

> Functional programming could be particularly hard to teach since it is
> generally made up of numerous small units of work combined in a complex
> way. This is precisely the formula for something that beginners will
> find extremely challenging. 

> When functional programming is dumbed down enough for a beginner to be 
> able to grok it, the programming problems start to look really lame. It 
> needn't be that way, of course, but it takes a good deal of creativity 
> on the part of the instructor. If Factorial doesn't turn you on, you 
> might be screwed. ;)

Did you see my example a bit earlier on Catalan numbers?  I believe it
explains them better -- certainly more succinctly -- than the
math+verbiage you can find at:
http://en.wikipedia.org/wiki/Catalan_number

Yes it may be hard to grok but I think its the exact opposite of
'numerous small units'

[toc] | [prev] | [next] | [standalone]

#76153

On 8/12/2014 1:40 PM, Neil D. Cerutti wrote:
> 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.

Or one can put the multiple steps in a file and step through with a 
debugger that shows local name values, like the Idle debugger.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#76016

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

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web