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 1 of 4  [1] 2 3 4  Next page →

#75925 — Re: how to get the ordinal number in list

 >>> x=["x1","x3","x7","x5","x3"]
 >>> x.index("x3")
1
if i want the result of 1 and 4 ?

On 8/8/2014 7:25 PM, Larry Martell wrote:
> On Sat, Aug 9, 2014 at 1:22 PM, luofeiyu <elearn2014@gmail.com> wrote:
>>>>> x=["x1","x3","x7","x5"]
>>>>> y="x3"
>>   how can i get the ordinal number by some codes?
>>
>> for id ,value in enumerate(x):
>>      if y==value : print(id)
>>
>> Is more simple way to do that?
> print x.index(y)

[toc] | [next] | [standalone]

#75931

luofeiyu wrote:

>  >>> x=["x1","x3","x7","x5","x3"]
>  >>> x.index("x3")
> 1
> if i want the result of 1 and 4 ?

def index_all(source, target):
    results = []
    for i, obj in enumerate(source):
        if obj == target:
            results.append(i)
    return results

index_all(x, "x3")
=> returns [1, 3]




-- 
Steven

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

#75932

On Saturday, August 9, 2014 8:36:28 AM UTC+5:30, Steven D'Aprano wrote:
> luofeiyu wrote:

> >  >>> x=["x1","x3","x7","x5","x3"]
> >  >>> x.index("x3")
> > 1
> > if i want the result of 1 and 4 ?

> def index_all(source, target):
>     results = []
>     for i, obj in enumerate(source):
>         if obj == target:
>             results.append(i)
>     return results

> index_all(x, "x3")
> => returns [1, 3]

Heh!
And the OP asked for a simplification!

>>> def index_all(lst, val): return (i for i,v in enumerate(lst) if v == val)
... 
>>> index_all("abcdeaga", "a")
<generator object <genexpr> at 0x7f21884797d0>
>>> list(index_all("abcdeaga", "a"))
[0, 5, 7]

[To the OP]
Yeah I am in the minority at least out here in considering
comprehensions simpler than loops. Take your pick

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

#75947

In article <338e8fb0-c9ec-462a-b560-1c1ff77de17e@googlegroups.com>,
 Rustom Mody <rustompmody@gmail.com> wrote:

> [To the OP]
> Yeah I am in the minority at least out here in considering
> comprehensions simpler than loops. Take your pick

When comprehensions first came out, I stubbornly refused to get my head 
around them.  Now, I'm totally addicted.  To the extent that I consider 
dict comprehensions to the THE killer feature of 2.7 :-)

But, putting on my instructor's hat, I think it's important to answer 
questions at a level that can be understood by the student.  Painting 
with a broad brush, there's three or four kinds of people asking 
questions on this list:

1) People who are totally new to programming, and are learning Python as 
their first language.  These are the people who are still struggling to 
understand fundamental concepts.  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.

2) People who are (at least somewhat) experienced programmers, and are 
learning Python as a second language.  Their experiential background is 
limited to one way of doing things (i.e. the Java way, or the PHP way, 
or whatever language way they learned first).  They mostly should be 
shown how translate the things they already know into familiar feeling 
constructs.  You already know how to write a loop, this is how we do it 
in Python.  You already know how build a data structure that maps keys 
to values, this is how we do it in Python.  Only after they've become 
comfortable with that, should they start exploring the really cool 
features of Python.

3) People who already know many languages, and are learning Python as 
their n-th.  These folks have seen multiple ways of doing things, and 
can understand concepts at a higher level.  Oh, Python dicts are more 
like C++ STL maps than PHP arrays.  Oh, variables have function scope 
and don't have to be explicitly declared.  Oh, RAII is spelled "with" in 
this language.  Oh, functions are first-class objects, but code blocks 
are not.

4) People who are already proficient Python programmers and are looking 
to explore deeper topics.

I think suggesting comprehensions in an answer should be reserved for 
people at levels 3 and 4.  Maybe level 2-1/2.  Certainly not level 1.

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

#75960

Roy Smith wrote:

> But, putting on my instructor's hat, I think it's important to answer
> questions at a level that can be understood by the student.  Painting
> with a broad brush, there's three or four kinds of people asking
> questions on this list:
[...]
> I think suggesting comprehensions in an answer should be reserved for
> people at levels 3 and 4.  Maybe level 2-1/2.  Certainly not level 1.

Yes, this! Strongly agreed.



-- 
Steven

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

#75983

On Saturday, August 9, 2014 9:04:22 PM UTC+5:30, Roy Smith wrote:
>  Rustom Mody  wrote:

> > [To the OP]
> > Yeah I am in the minority at least out here in considering
> > comprehensions simpler than loops. Take your pick

> When comprehensions first came out, I stubbornly refused to get my head 
> around them.  Now, I'm totally addicted.  To the extent that I consider 
> dict comprehensions to the THE killer feature of 2.7 :-)

Yeah I remember seeing a stunning example from Peter Otten a few months(?)
ago... first I heard of them. If someone can track that example down...
I'll be mighty pleased.

> But, putting on my instructor's hat, I think it's important to answer 
> questions at a level that can be understood by the student.  Painting 
> with a broad brush, there's three or four kinds of people asking 
> questions on this list:

> 1) People who are totally new to programming, and are learning Python as 
> their first language.  These are the people who are still struggling to 
> understand fundamental concepts.  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.

> 2) People who are (at least somewhat) experienced programmers, and are 
> learning Python as a second language.  Their experiential background is 
> limited to one way of doing things (i.e. the Java way, or the PHP way, 
> or whatever language way they learned first).  They mostly should be 
> shown how translate the things they already know into familiar feeling 
> constructs.  You already know how to write a loop, this is how we do it 
> in Python.  You already know how build a data structure that maps keys 
> to values, this is how we do it in Python.  Only after they've become 
> comfortable with that, should they start exploring the really cool 
> features of Python.

> 3) People who already know many languages, and are learning Python as 
> their n-th.  These folks have seen multiple ways of doing things, and 
> can understand concepts at a higher level.  Oh, Python dicts are more 
> like C++ STL maps than PHP arrays.  Oh, variables have function scope 
> and don't have to be explicitly declared.  Oh, RAII is spelled "with" in 
> this language.  Oh, functions are first-class objects, but code blocks 
> are not.

> 4) People who are already proficient Python programmers and are looking 
> to explore deeper topics.

> I think suggesting comprehensions in an answer should be reserved for 
> people at levels 3 and 4.  Maybe level 2-1/2.  Certainly not level 1.

All this... (and in particular)

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

- CS is defined as the science of algorithms (or algorithmics)
- 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.

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

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.

[This also BTW implies that in the python world the 'sorted' function is
more fundamental than the sort (mutating) method. And their names are
pedagogically the wrong way round.  Of course this is for historical reasons.

But for now let us wear instructor not historian hats shall we?]

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

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.

I believe this is more important than the NO ASSIGNMENT.

Assignments can become a religious issue one way or other.
However if beginning students start off writing print statements too easily,
it becomes very hard to progress from toy egs to more reusable, modular stuff.

So yes I may have been a bit remiss in missing pedagogic steps in showing:

>>> def index_all(lst, val): return (i for i,v in enumerate(lst) if v == val) 

Perhaps a right in between step would be a point in the spectrum between mine
and Steven's 

> def index_all(source, target):
>     results = []
>     for i, obj in enumerate(source):
>         if obj == target:
>             results.append(i)
>     return results 

viz.

def index_all(source, target):
    for i, obj in enumerate(source):
        if obj == target:
            yield i

And now someone is going to say:
"yield (generators/iterators etc) are advanced whereas lists (append
etc) are easier"
and the argument loop starts over!


So before that comes let me preempt by saying that when I write
the python

def index_all(lst, val): return (i for i,v in enumerate(lst) if v == val) 

I am using python as 'assembly language' (so to speak) and
using a pidgin Haskell-ish math language to think with in which it would 
look something like

{i | (i,v) ∈ zip.lst.[0...],  v = val }

IOW as long as we think (and teach) that a comprehension:*

squares = [x**2 for x in range(10)]

is equivalent to 

squares = []
for x in range(10):
    squares.append(x**2)

the comprehensions will seem advanced but ultimately an engineering trick.

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

then it would

- not seem difficult/advanced etc
- it would be seen/felt to be more fundamental and not just an engineering trick



* I have to say that this example comes from the official tutorial
itself... Unfortunate...

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

#75988

In article <b5ac5b12-cda7-464e-9c14-63ef184a7a10@googlegroups.com>,
 Rustom Mody <rustompmody@gmail.com> 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.

(*) Yes, I know, that's not the optimum way, but it's a reasonable first 
attempt.

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

#75992

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.

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.

I can do

>>> sorted(l)[-5:]
[2, 4, 6, 9, 12]

But that's a bit arcane

In any case coming back to the point

All the above are clearer than loops+assignments and can be 
taught before them

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

#75995

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)
> >>> l2[:5]

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.

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

#75996

On Sunday, August 10, 2014 11:44:23 PM UTC+5:30, 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)
> > >>> l2[:5]

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


Yeah Whats the disagreement??

You are writing straight-line code.
I am recommending straight-line code -- another way of saying loops are bad.

Or is it because you are using assignment?

I call that 'nominal' assignment.
Technically its called 'single-assignment'
www.cs.princeton.edu/~appel/papers/ssafun.ps

Its when we have variables that are assigned in multiple places that
we start seeing mathematical abominations like
x = x+1

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

#75999

On Mon, Aug 11, 2014 at 4:26 AM, Rustom Mody <rustompmody@gmail.com> wrote:
>
> Its when we have variables that are assigned in multiple places that
> we start seeing mathematical abominations like
> x = x+1

That's an abomination to you because it breaks your mathematical
model. It's fine to a computer, which has a sense of time. And it even
can be strictly true. Consider:

>>> x = 2.0**53
>>> x = x + 1
>>> x == x + 1
True

x is clearly not infinity, yet it's equal to itself plus one. If
you're going to try to pretend that maths and computers are exactly
the same, you have a LOT of problems to deal with.

In computing, assignment and reassignment aren't at all problematic,
and neither is printing to the console, so please stop telling people
off for using them.

ChrisA

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

#76000

Chris Angelico <rosuav@gmail.com>:

> In computing, assignment and reassignment aren't at all problematic,
> and neither is printing to the console, so please stop telling people
> off for using them.

Printing to the console is somewhat problematic:

   >>> with open("/dev/console", "w") as console: console.write("hello\n")
   ... 
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   IOError: [Errno 13] Permission denied: '/dev/console'


Marko

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

#76001

On Mon, Aug 11, 2014 at 5:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> In computing, assignment and reassignment aren't at all problematic,
>> and neither is printing to the console, so please stop telling people
>> off for using them.
>
> Printing to the console is somewhat problematic:
>
>    >>> with open("/dev/console", "w") as console: console.write("hello\n")
>    ...
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>    IOError: [Errno 13] Permission denied: '/dev/console'

Har har :) I meant printing to the single most obvious destination,
which is a combination of stdout and stderr (the latter for error
tracebacks, by default).

What he's saying is basically "print is EVIL, so do everything with
the REPL, and pretend that the P in REPL doesn't stand for print".
Apparently the idea that code should work from a .py file is foreign
to him.

ChrisA

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

#76022

On Monday, August 11, 2014 12:33:59 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 4:26 AM, 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 an abomination to you because it breaks your mathematical
> model. It's fine to a computer, which has a sense of time.

It does?!?!
Completely missed the news flash

Last I knew they were as dumb as a rock -- maybe a GHz rock

A C programmer asked to swap variables x and y, typically writes something like

t = x; x = y; y = t;

Fine, since C cant do better.
But then he assumes that that much sequentialization is inherent to the problem...
Until he sees the python:

x,y = y,x

The same applies generally to all programmers brought up on imperative style.

Yeah there are problems that need to address time -- OSes, network
protocols, reactive systems like window managers etc

But the vast majority of problems that a programmer is likely to solve dont need time.

These are of the form: Given this situation, this is the desired outcome.

Nothing wrong with giving a sequential solution to a not inherently sequential problem.

What is wrong is then thinking that all *problems* are sequential rather than
seeing that some over-specific sequential *solutions* to non-sequential problems are ok.

A mindset exemplified by your hilarious statement: "computers have a sense of time"

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

#76025

On Mon, Aug 11, 2014 at 3:23 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> A C programmer asked to swap variables x and y, typically writes something like
>
> t = x; x = y; y = t;
>
> Fine, since C cant do better.
> But then he assumes that that much sequentialization is inherent to the problem...
> Until he sees the python:
>
> x,y = y,x
>
> The same applies generally to all programmers brought up on imperative style.

Uhh, that's still imperative. There is a chronological boundary here:
prior to that statement's execution, x and y have certain values, and
after it, they have the same values but the other way around. When
you're manipulating algebraic statements, moving down the page doesn't
correspond to any sort of time change, which is why "x = x + 1" has no
solutions.

Please explain to me how "x,y = y,x" is materially different from "x =
x + 1" in that the latter is, in your words, an abomination, but you
say the former doesn't have the same problem.

ChrisA

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

#76027

On Monday, August 11, 2014 11:16:25 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Aug 11, 2014 at 3:23 PM, Rustom Mody wrote:
> > A C programmer asked to swap variables x and y, typically writes something like
> > t = x; x = y; y = t;
> > Fine, since C cant do better.
> > But then he assumes that that much sequentialization is inherent to the problem...
> > Until he sees the python:
> > x,y = y,x
> > The same applies generally to all programmers brought up on imperative style.

> Uhh, that's still imperative. There is a chronological boundary here:
> prior to that statement's execution, x and y have certain values, and
> after it, they have the same values but the other way around. When
> you're manipulating algebraic statements, moving down the page doesn't
> correspond to any sort of time change, which is why "x = x + 1" has no
> solutions.

> Please explain to me how "x,y = y,x" is materially different from "x =
> x + 1" in that the latter is, in your words, an abomination, but you
> say the former doesn't have the same problem.

I was giving an analogy for a mindset that

- is sequencing hungup
- is not aware of being hungup

until a more abstract solution is presented.

The two -- x=x+1 and the swap -- are not related.
And yes the swap is imperative but less so than the C
because it elides the fact that an implementation of x,y = y,x
could be
- t=x;x=y;y=t			# the original
- t=y;y=x=x=t			# in the reverse order
- push x; push y; pop x; pop y	# use stack no temporary
- xchng x y			# hardware instruction in x86

and perhaps many other plausible ones.

The terrible thing about an overspecific presentation is that it blinds one 
to alternatives

And as for your wanting a fully non-imperative version:

swap (x, y) = (y, x)

-- the only option in Haskell, natural/easy in python, painfully
laborious but still possible in C -- pass a struct, return a struct,
unpack on return.

You think that the '=' sign not standing for math equality is ok.

How come?

I aver that you (any competent programmer) have worked out/crystallized/created
a switch in your brain.  

In 'programming' state: x=x+1 is not a problem
In 'math' state : it is

And you have become adroit at flipping from one to the other -- you do it
all the time going from rhs to lhs!!

I too have that switch as do most practised programmers.

We are not talking about us, we are talking about noobs.

So my reverse question to you is how do you inculcate this switch in a noob?

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

#76031

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.



-- 
Steven

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

#76035

On Mon, Aug 11, 2014 at 6:55 PM, Steven D'Aprano <steve@pearwood.info> 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.

Thanks, you said it better than I would have. That's exactly the
sentiment I would have expressed, and while I hate to "Me too" a post,
I'll do it here. +1.

ChrisA

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

#76036

Rustom Mody <rustompmody@gmail.com>:

> You think that the '=' sign not standing for math equality is ok.
>
> How come?

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.

Instead of fighting the crystal-clear status of the = symbol in Python,
you should choose a worthier crusade. For example, you could help
mathematicians and physicists agree on the meaning of

  6 3
  ∫ ∫ f(x, y) dy dx
  0 2

The mathematicians maintain the expression means x ranges from 0 to 6
and y from 2 to 3. The physicists consider that too confusing in
practice and insist it is y that ranges from 0 to 6 and x from x to 3.


Marko

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

#76039

On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa <marko@pacujo.net> 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

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

ChrisA

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web