[Errk]

import random

for i in range(5):
  x=random.randrange (0,101, 1)
  list= (x)
  printNow(list)

so i'm new to coding, but excited to learn. i've got 2 questions. when executed, is this considered a list? i feel like a list would be more like (1,2,3,4,5). secondly what function do i call to find the max number of a list? hope im not asking for too much info, thanks lots

[jon.kiparsky]

(x) is a tuple. [x] is a list.

A list can be empty:

l = list()

will give you one of those.
Or it can have members:

l = [5,6,2,3]

or it can have a single member:

l = ["lonely list element"]

Quote

secondly what function do i call to find the max number of a list?

max()
Like this:

>>> max([1,2,3])
3

Quote

hope im not asking for too much info, thanks lots

Not at all.

This post has been edited by jon.kiparsky: 16 October 2012 - 01:30 PM

[Errk]

hmm i may not be getting what u say completely, i thought i was but i can't figure out how to get the 5 random numbers in a list. i tried

import random

for i in range(5):
  x=random.randrange (0,101, 1)
  l=list(x)
  printNow(x)

im not sure if that was even in the right direction i was suppose to do

[jon.kiparsky]

The simplest, most iterative, and least python way would be

l = list()   # please don't call your list "list"
for i in range(5):
  l.append(random.randrange (0,101, 1))

There are cooler ways, but this is the easiest to get your head around.

Notice that "i" is simply a counter here - we never refer to it at all.

[sepp2k]

jon.kiparsky, on 16 October 2012 - 10:28 PM, said:

(x) is a tuple.

No, it's not. (x) is just x¹. (x,) is a tuple.

¹ This is because any expression can be surrounded by parentheses without altering its semantic in almost any language that isn't Lisp. It would be pretty annoying if expressions like (a + b) * c would fail to execute because you're trying to multiply a tuple and a number.

This post has been edited by sepp2k: 16 October 2012 - 07:49 PM
Reason for edit:: Tangent removed to not clutter the thread

[jon.kiparsky]

sepp2k, on 16 October 2012 - 08:42 PM, said:

jon.kiparsky, on 16 October 2012 - 10:28 PM, said:

(x) is a tuple.

No, it's not. (x) is just x¹. (x,) is a tuple.

That's correct. My bad - goes to show there are little syntax traps in every language. As you say, there's a good reason for it.

Quote

<total-tangent>

Quote

There are cooler ways, but this is the easiest to get your head around.

Are you sure about that? I'm not an educator, but I could imagine that something like a list comprehension (which is very close to the set-notation that one knows from math class) would be more familiar (and thus easier to understand) to newbies who aren't used to imperative loops and mutation.

I actually don't think the list comprehension syntax is nearly as clear as the die-hard pythonistas seem to find it, and I have watched other people try to learn it - they struggled with it as well. These included both novices and some people with extensive programming experience. It's just really not that intuitive.
Speaking generally, I find that the concepts of functional programming are not generally easier to learn than imperative concepts. Once learned, they're generally easier to use, but that's a very different thing. The same goes for the syntax of these languages - there's a ton of gotchas in python, and Scala has just as many traps. Like any language, you just have to learn them, but it's not any easier than Java or C. What's easier (again) is doing cool stuff with them once you learn them.
I have only my experience and some anecdotal evidence to support this, but looking at the forum chatter in the Odersky scala course might bear me out. The people insisting that these concepts are easy seem to mostly be people already familiar with them. The people new to the ideas are struggling hard, and it's really no help to them to tell them "but it's so easy!". (which is the usual response from the people who get it already)

(you can sign up for the course at coursera if you want to check out the forum chatter and draw your own conclusions)

But perhaps we should fork this if we want to pursue this tangent, no need to hijack this thread for it.

[sepp2k]

jon.kiparsky, on 17 October 2012 - 04:30 AM, said:

But perhaps we should fork this if we want to pursue this tangent, no need to hijack this thread for it.

Good idea, let's move this here.

[jon.kiparsky]

Thanks for that, Sepp. Now, to return to the topic at hand, here's one of the cooler ways that I mentioned. It's called a list comprehension. Here's an example (that does what you're trying to do)

l = [random.randrange(0,101,1) for i in range(5)]

I'd probably do better to let Sepp explain it but you can think of it this way:

the expression random.randrange(0,101,1) is your original call. It is evaluated for each i, where i takes the values in the specified sequence, and the resulting values are collected in a list, which is the value of this expression. Note that again "i" is not used in the evaluation of the randrange expression - just like in the version we saw before. (did you wonder why I mentioned that?)
Just like in that expression, i is available to be used. For example:

l = [i * random.randrange(0,10) for i in range (5)]

Here, we take each value of i and multiply it by some random value in the given range.

This is easy to explain as an inversion of the previous version, but this is not just syntactic sugar! This is not just about saving a few keystrokes, and this is very important to point out. This form allows the language to recognize a common pattern - iterating over values to produce a list - and specialize itself to do that job well. So whether or not you find this more natural, it's a safe bet that this will work better than the equivalent imperative construction. There are two ways to demonstrate this. One, which I will leave to Sepp involves knowing something about what exactly python does to make this work better. The other is a simple deduction: it is obvious that this form is transparently convertible to the other form. It is obvious that it is much harder to convert the imperative form to this form - it would have to recognize that a given loop over a range generated a list, and it would have to know whether it was appending to an existing list, and so forth.
Therefore, if there is any optimization possible for the specific case of generating a list from iterating over a sequence, than that will be possible to apply when using the listcomp syntax, and not when using the more general form.
Since it is extremely likely that a more specific case offers some possibility of optimization over the general case, and it is certain that the more specific syntax is no less efficient that the more general, it is a safe bet that you will get advantage from using list comprehensions - you're likely to gain by it, and you can't lose.

This post has been edited by jon.kiparsky: 16 October 2012 - 08:21 PM

[sepp2k]

jon.kiparsky, on 17 October 2012 - 05:20 AM, said:

l = [random.randrange(0,101,1) for i in range(5)]

I'd probably do better to let Sepp explain it but you can think of it this way:

the expression random.randrange(0,101,1) is your original call. It is evaluated for each i, where i takes the values in the specified sequence, and the resulting values are collected in a list, which is the value of this expression.

I'd probably phrase this as "l is set to be the list containing the result of evaluating random.randrange(0,101,1) for each i in the range from 0 to 5 (exclusive) because that explanation most closely resembles the structure of the code.

Of course the whole thing would be more natural if it weren't for the unused variable i, i.e. if Python had a way of saying "5 times" (without introducing any variable) instead of "for each i in range(5)". But it doesn't, so that's that.

Quote

So whether or not you find this more natural, it's a safe bet that this will work better than the equivalent imperative construction. There are two ways to demonstrate this. One, which I will leave to Sepp involves knowing something about what exactly python does to make this work better.

Sorry, I'm not quite sure what you're getting at here.

[jon.kiparsky]

[quote name='sepp2k' date='16 October 2012 - 10:33 PM' timestamp='1350444818' post='1725141']

Quote

I'd probably phrase this as "l is set to be the list containing the result of evaluating random.randrange(0,101,1) for each i in the range from 0 to 5 (exclusive) because that explanation most closely resembles the structure of the code.

That's a more concise statement of the case. I clearly need to write more functional and less imperative code.

Quote

Of course the whole thing would be more natural if it weren't for the unused variable i, i.e. if Python had a way of saying "5 times" (without introducing any variable) instead of "for each i in range(5)". But it doesn't, yet so that's that, for now.

One nice thing about python is, it always seems to be improving. And the improvements are actual improvements, unlike some large languages that I work in which will not be named... So I took the liberty of improving your text a little.

Quote

Sorry, I'm not quite sure what you're getting at here.

That's me trying to put you on the spot. I'm assuming that python does optimize listcomps in some devilishly clever fashion rather than simply converting them to standard imperative loops, and I was hoping you might be able to shed some light on those.
This way I get to explain the easy stuff, and I make you explain the hard stuff.

This post has been edited by jon.kiparsky: 16 October 2012 - 08:59 PM

[sepp2k]

jon.kiparsky, on 17 October 2012 - 05:58 AM, said:

That's me trying to put you on the spot. I'm assuming that python does optimize listcomps in some devilishly clever fashion rather than simply converting them to standard imperative loops, and I was hoping you might be able to shed some light on those.
This way I get to explain the easy stuff, and I make you explain the hard stuff.

I actually no very little about Python's implementation details and what optimizations it does. One thing I could imagine it does, is that if a list comprehension contains no ifs and all the source iterables are lists, it could allocate a list of the proper size (which in the absence of ifs can be easily calculated by multiplying the lengths of the source lists) right away, instead of resizing the list while appending to it. But I have no idea whether it actually does this.

What I do know is that calling methods and functions (especially ones implemented in C) in dynamic languages can have quite a bit of performance overhead compared to calling them directly from C. So simply having the calls to append happen inside the interpreter instead of the Python code can already account for a significant performance increase.

[jon.kiparsky]

sepp2k, on 16 October 2012 - 11:30 PM, said:

I actually no very little about Python's implementation details and what optimizations it does. One thing I could imagine it does, is that if a list comprehension contains no ifs and all the source iterables are lists, it could allocate a list of the proper size (which in the absence of ifs can be easily calculated by multiplying the lengths of the source lists) right away, instead of resizing the list while appending to it. But I have no idea whether it actually does this.

What I do know is that calling methods and functions (especially ones implemented in C) in dynamic languages can have quite a bit of performance overhead compared to calling them directly from C. So simply having the calls to append happen inside the interpreter instead of the Python code can already account for a significant performance increase.

This is why you get asked these questions. Even when you don't know, you come up with good answers.

[atraub]

I always parsed it like this... Start at the for and read left to right, when you get to the end add the word append and then wrap around until you hit the for. For example:

[i for i in range(5)]
for each value "i" from 0 to 5, append i

or

[i for i in range(5) if i%2]
for each value "i" from 0 to 5, if i has a remainder when divided by 2, append i

It always worked for me, but I dunno.

This post has been edited by atraub: 16 October 2012 - 11:12 PM

[jon.kiparsky]

Nice. I like it.