Re: [Tutor] Lotka-Volterra Model Simulation Questions
On Sep 29, 2012 2:25 AM, "Alan Gauld" wrote: > > On 28/09/12 21:32, Jim Apto wrote: > >> I'm relatively new to python, and was asked to program a lotka-volterra >> model (predator and prey relation) simulator. > > > No idea what that means in practice but commenting purely on the code provided... > > >> x represents prey population >> y represents predator population > > > so use names that say so, like preyPop and predatorPop > Its only a few extra letters typing but makes things much more readable. As a mathematician I'd have to disagree with you there Alan. This model already has an established notation: http://en.m.wikipedia.org/wiki/Lotka%E2%80%93Volterra_equation ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On Sep 29, 2012 9:41 AM, "Oscar Benjamin" wrote: > > > On Sep 29, 2012 2:25 AM, "Alan Gauld" wrote: > > > > On 28/09/12 21:32, Jim Apto wrote: > > > >> I'm relatively new to python, and was asked to program a lotka-volterra > >> model (predator and prey relation) simulator. > > > > > > No idea what that means in practice but commenting purely on the code provided... > > > > > >> x represents prey population > >> y represents predator population > > > > > > so use names that say so, like preyPop and predatorPop > > Its only a few extra letters typing but makes things much more readable. > > As a mathematician I'd have to disagree with you there Alan. This model already has an established notation: > http://en.m.wikipedia.org/wiki/Lotka%E2%80%93Volterra_equation Accidentally sent that prematurely. I meant to say that changing the notation will only lead to confusion. Also there are good reasons for using short names in equations. It makes it much easier to see the whole equation at once, which makes it easier to understand the equations and easier to check your code. If you make the variable names too long, even simple equations like these will have to split over several lines and be more difficult to read/check. Oscar ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On 29/09/12 09:41, Oscar Benjamin wrote: > so use names that say so, like preyPop and predatorPop > Its only a few extra letters typing but makes things much more readable. As a mathematician I'd have to disagree with you there Alan. This model already has an established notation: I did say I had no idea about the original algorithm so yes, if the variable names are industry standardised and the people working with the code are familiar with them then it may be better to stick with them, even if nobody else on the planet understands the resultant code. As to using short names to keep things on a single line, there is a huge body of research in Comp Science that shows that meaningful names outweigh single line expressions every time in terms of reliability, comprehension, ease of maintenance etc. Of course we shouldn't go overboard but keeping to a single line is not a good reason, on its own, to use single char variable names. Industry standards however may be... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On 29/09/12 19:16, Alan Gauld wrote: On 29/09/12 09:41, Oscar Benjamin wrote: > so use names that say so, like preyPop and predatorPop > Its only a few extra letters typing but makes things much more readable. As a mathematician I'd have to disagree with you there Alan. This model already has an established notation: I did say I had no idea about the original algorithm so yes, if the variable names are industry standardised and the people working with the code are familiar with them then it may be better to stick with them, even if nobody else on the planet understands the resultant code. :) One advantage of using single-letter names in a function when the rest of your module uses descriptive names is that it immediately screams "mathematical formula". If that means the programmer seeks help from an expert sooner, that's a good thing :) As to using short names to keep things on a single line, there is a huge body of research in Comp Science that shows that meaningful names outweigh single line expressions every time in terms of reliability, comprehension, ease of maintenance etc. Yes, but "meaningful names" is relative to the reader, and depends on their familiarity with the topic on hand. To *some* degree, you can overcome a lack of familiarity with longer, more descriptive names, but that soon becomes painful and even unreadable. To a mathematician, "pi" or "π" is meaningful, and "constant_ratio_of_diameter_to_circumference" would be much harder to read. To a physicist, the names "E", "p", "m", "c", "e", "v", "a", etc. are all meaningful, and while it wouldn't hurt *that* much to write them as "energy", "momentum", "rest_mass", "speed_of_light", "charge_on_the_electron", "velocity", "acceleration" that soon gets tedious and frankly it doesn't help that much. If somebody doesn't understand: p = m*v*(1-(c/v)**2)**-0.5 they aren't likely to be much enlightened by: momentum = rest_mass*velocity*(1-(speed_of_light/velocity)**2)**-0.5 and of course, the longer names aren't likely to help the programmer find the bug in the expression if he doesn't know the subject well. Meaningful names are vital. But short names, even single letters, are not necessarily less meaningful than longer, more descriptive names. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On 29/09/2012 11:42, Steven D'Aprano wrote: On 29/09/12 19:16, Alan Gauld wrote: On 29/09/12 09:41, Oscar Benjamin wrote: Meaningful names are vital. But short names, even single letters, are not necessarily less meaningful than longer, more descriptive names. I suspect that every experienced programmer has worked on a project where naming standards are enforced so you end up with aVeryLongPackageNameAVeryLongModuleNameI. IMHO as useful as a chocolate teapot. -- Cheers. Mark Lawrence. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On Sep 29, 2012 11:52 AM, "Steven D'Aprano" wrote: > > On 29/09/12 19:16, Alan Gauld wrote: >> >> As to using short names to keep things on a single line, there is a huge >> body of research in Comp Science that shows that meaningful names outweigh >> single line expressions every time in terms of reliability, comprehension, >> ease of maintenance etc. > > If somebody doesn't understand: > > p = m*v*(1-(c/v)**2)**-0.5 It should be v/c not c/v. To give some relevance to this otherwise pedantic post I'll say that I find it much easier to spot the mistake in the line above than the line below. This is precisely because the line above resembles the way the equation would normally be written in a book or on the blackboard etc. > > they aren't likely to be much enlightened by: > > momentum = rest_mass*velocity*(1-(speed_of_light/velocity)**2)**-0.5 > Oscar ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On Sat, 29 Sep 2012, Oscar Benjamin wrote: On Sep 29, 2012 2:25 AM, "Alan Gauld" wrote: > > On 28/09/12 21:32, Jim Apto wrote: > >> I'm relatively new to python, and was asked to program a lotka-volterra >> model (predator and prey relation) simulator. > > >> x represents prey population >> y represents predator population > > > so use names that say so, like preyPop and predatorPop > Its only a few extra letters typing but makes things much more readable. As a mathematician I'd have to disagree with you there Alan. This model already has an established notation: Regardless of established notation, unless only mathematicians will be reading the code, and only those intimately familiar with the equation, it makes much more sense to use meaningful names. Because that way, when sending the code to a mailing list full of non-mathematician programmers, they'll know exactly what the variables are supposed to be for, so they wont have to look anything up on wikipedia. After all, they've got a finite amount of volunteer time, and would you prefer to get more advice about logic errors, or the guarenteed responses about variable names? I for one, prefer to get the most value from my question as possible. It shows respect to the people I'm asking, and to everything else that they could possibly be spending their time on, including answering other questions. Respectfully-and-somewhat-tongue-in-cheekily, Wayne ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On Sat, 29 Sep 2012, Wayne Werner wrote:
On Sat, 29 Sep 2012, Oscar Benjamin wrote:
On Sep 29, 2012 2:25 AM, "Alan Gauld" wrote:
>
> On 28/09/12 21:32, Jim Apto wrote:
>
>> I'm relatively new to python, and was asked to program a lotka-volterra
>> model (predator and prey relation) simulator.
>
>
>> x represents prey population
>> y represents predator population
>
>
> so use names that say so, like preyPop and predatorPop
> Its only a few extra letters typing but makes things much more readable.
As a mathematician I'd have to disagree with you there Alan. This model
already has an established notation:
Regardless of established notation, unless only mathematicians will be
reading
the code, and only those intimately familiar with the equation, it makes much
more sense to use meaningful names.
And lest I sound like I'm completely ignoring the mathematical aspect -
what *does* make sense to do is this:
x = prey_popluation
y = pred_population
# insert mathematical formula here.
This satesfies all parties:
1) It gives us programmers nice, meaningful names
2) It gives mathematicians the formula that screams "FORMULA!"
3) It clearly separates the math-y bits from the program-y bits.
Because let's face it,
x = float(input("Starting Prey Population: "))
isn't exactly something you find in (most) math classes. And I think
clearly separating concerns is always a good thing.
-Wayne
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
[Tutor] generic repr method?
Hi,
I've written a __repr__ method that is supposed to *always* work. That is, it
returns an eval-able text representation of any class instance.
Will this really always work? I'd find it useful is this is standard behavior
of Python. Or am I overlooking something?
import inspect
class X (object):
def __init__(self, x=1, y='n'):
self.x = x
self.y = y
def __repr__(self):
code = self.__class__.__name__ + "("
for arg in inspect.getargspec(self.__init__).args [1:] :
if isinstance(eval("self." + arg), basestring):
code += ("%(" + arg + ")r, ")
else:
code += ("%(" + arg + ")s, ")
code = code[:-2] + ")"
return code % self.__dict__
x = X()
eval(repr(x))
Regards,
Albert-Jan
~~
All right, but apart from the sanitation, the medicine, education, wine, public
order, irrigation, roads, a
fresh water system, and public health, what have the Romans ever done for us?
~~
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On 28 September 2012 21:32, Jim Apto wrote: > Hello folks, > > I'm relatively new to python, and was asked to program a lotka-volterra > model (predator and prey relation) simulator. The program basically will > basically have a menu that takes user input, collect data, and then create > a graph. Currently i've been working on the simulator section; I can't > seem to get the lists right. > Jim, I apologise if the responses to your original post seem to have gotten distracted from the problems you're having. Also I'm sorry if my first post was a bit abstract. Have the responses so far been helpful? Oscar ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On 29/09/12 11:42, Steven D'Aprano wrote: On 29/09/12 19:16, Alan Gauld wrote: I did say I had no idea about the original algorithm so yes, if the variable names are industry standardised and the people working with the code are familiar with them then it may be better to stick with them, As to using short names to keep things on a single line, there is a huge body of research in Comp Science that shows that meaningful names outweigh single line expressions every time in terms of... Yes, but "meaningful names" is relative to the reader, Absolutely, see the first para above. This latter comment was explicitly in response to the snipped (by me) context: "Also there are good reasons for using short names in equations. It makes it much easier to see the whole equation at once, which makes it easier to understand the equations and easier to check your code. If you make the variable names too long, even simple equations like these will have to split over several lines and be more difficult to read/check." To a mathematician, "pi" or "π" is meaningful, and "constant_ratio_of_diameter_to_circumference" would be much harder to read. Totally agree. My point is that we should not choose short names just to keep an expression on a single line. The evidence suggests that the advantages of longer names outweigh the advantage of a single line. But in the cases here where single letters evidently have expressive power in their own right the familiar term is preferable over a longer descriptive name. Of course, care is needed when splitting an expression over multi lines to keep the readability so if the terms can be naturally split by operator then that's the place to split them. But this is the same in written math too. (Most of the equations I remember reading from my quantum mechanics days were split over at least 3 lines... trying to force them into a single line would not have made them any more palatable!) p = m*v*(1-(c/v)**2)**-0.5 they aren't likely to be much enlightened by: momentum = rest_mass*velocity*(1-(speed_of_light/velocity)**2)**-0.5 I'm slightly less convinced by that. I rarely learned Physics formulae by wrote because I could usually work them out from first principles easily enough. So knowing what the variables represent would help me more than an equation of single letters if it was an equation I hadn't seen before. But where it is an industry standard equation using industry standard symbols then for sure, stick to the standard. and of course, the longer names aren't likely to help the programmer find the bug in the expression if he doesn't know the subject well. Agreed, but if he knows the subject area but not the specific algorithm it might help (again assuming standard symbology is used appropriately). Meaningful names are vital. But short names, even single letters, are not necessarily less meaningful than longer, more descriptive names. Absolutely. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On 29 September 2012 22:57, Alan Gauld wrote: > On 29/09/12 11:42, Steven D'Aprano wrote: > >> On 29/09/12 19:16, Alan Gauld wrote: >> > Totally agree. > My point is that we should not choose short names just to keep an > expression on a single line. The evidence suggests that the advantages of > longer names outweigh the advantage of a single line. But in the cases here > where single letters evidently have expressive power in their own right the > familiar term is preferable over a longer descriptive name. > > Of course, care is needed when splitting an expression over multi lines > to keep the readability so if the terms can be naturally split by operator > then that's the place to split them. But this is the same in written math > too. (Most of the equations I remember reading from my quantum mechanics > days were split over at least 3 lines... trying to force them into a single > line would not have made them any more palatable!) I wouldn't advocate forcing an equation onto a single line if it doesn't fit on a single line. However, I'm sure that the equations you're refering to would have already been using lots of symbols described by very succinct single-greek/latin-letters and other simple glyphs. Naturally, these equations would not be meaningful to someone lacking prior experience of quantum mechanics. Now imagine replacing each of those single letter symbols with English underscore-separated words so instead of letter capital psi you would have 'time_dependent_wave_function' and instead of hbar you would have 'planks_constant_over_twopi' and so on. Your equation would go from three lines to thirty and noone would be able to understand it *even if they were familiar with the subject*. Oscar ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lotka-Volterra Model Simulation Questions
On Sat, Sep 29, 2012 at 2:16 AM, Alan Gauld wrote:
> As to using short names to keep things on a single line, there is a huge
> body of research in Comp Science that shows that meaningful names outweigh
> single line expressions every time in terms of reliability, comprehension,
> ease of maintenance etc.
With the nod to what exactly is meaningful vs noise, I'm in subjective
agreement. Can you point to any of the research you mention? I'd
like to read into to see how my personal experience equates with the
overall study - I might learn something!
One point of curiousity for me: in Perl there was a attempt a decade
ago to promote a change in how hashes (dicts) were named to better
match their usage (that is, rather than having a hash named for the
collection, e.g. %addresses, have your hash named to match the
singular usage: %address_of, which leads to $address_of{$student} ).
No idea if that caught on or not, as I spent a few years trapped in
Java, where the trend is to disguise everything in a mass of Verbed
Nouns.
Googling coughed up this link (
http://infoscience.epfl.ch/record/138586?ln=en&of=HD ), but I'm awash
in results about general discussions of variables in research rather
than studies about programming variable names (my google-fu is weak)
--
Brett Ritter / SwiftOne
swift...@swiftone.org
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] generic repr method?
On 29 September 2012 21:15, Albert-Jan Roskam wrote:
> Hi,
>
> I've written a __repr__ method that is supposed to *always* work. That is,
> it returns an eval-able text representation of any class instance.
> Will this really always work?
No.
> I'd find it useful is this is standard behavior of Python. Or am I
> overlooking something?
>
Yes.
>
>
> import inspect
>
> class X (object):
>
> def __init__(self, x=1, y='n'):
> self.x = x
> self.y = y
>
> def __repr__(self):
> code = self.__class__.__name__ + "("
> for arg in inspect.getargspec(self.__init__).args [1:] :
> if isinstance(eval("self." + arg), basestring):
>
I'd prefer getattr(self, arg) to eval("self." + arg).
> code += ("%(" + arg + ")r, ")
> else:
> code += ("%(" + arg + ")s, ")
> code = code[:-2] + ")"
> return code % self.__dict__
>
> x = X()
> eval(repr(x))
>
This repr method assumes that every argument to __init__ is stored as an
attribute with the same name as the parameter to __init__. Consider:
def __init__(self, name):
self.other_name = name
Also how do you handle:
def __init__(self, *args, **kwargs):
Oscar
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] generic repr method?
On Sat, Sep 29, 2012 at 4:15 PM, Albert-Jan Roskam wrote:
>
> def __repr__(self):
> code = self.__class__.__name__ + "("
> for arg in inspect.getargspec(self.__init__).args [1:] :
> if isinstance(eval("self." + arg), basestring):
> code += ("%(" + arg + ")r, ")
> else:
> code += ("%(" + arg + ")s, ")
> code = code[:-2] + ")"
> return code % self.__dict__
__init__ could use *args and **kwds.
Keyword-only arguments in Python 3 require using inspect.getfullargspec.
A class with __slots__ probably lacks a __dict__.
Use the repr of all values.
The current value of an attribute isn't necessarily the value needed
for initialization, nor do all initialization arguments necessarily
map to attributes. So you can't expect a general-purpose __repr__ to
capture everything that's needed to recreate the object. It's nice to
try for this, but not necessary. It is important, however, to include
information relevant for debugging:
http://docs.python.org/py3k/reference/datamodel.html#object.__repr__
Also see:
http://docs.python.org/py3k/library/copy
http://docs.python.org/py3k/library/pickle.html#pickling-class-instances
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] generic repr method?
On Sat, Sep 29, 2012 at 7:46 PM, eryksun wrote: > > A class with __slots__ probably lacks a __dict__. That didn't come out clearly. I meant *instances* of a class that defines __slots__. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Apprenticeships
Hey group, I have a bit of a non-technical question. I've seen quite a bit recently about the rise of software apprenticeships. As a self-taught developer, this looks quite appealing for a number of reasons. I'm wondering if anyone in the group knows of any apprenticeships (or, if not a formal apprenticeship, a shop that's looking for a very self-motivated Junior Dev that is quite eager to learn, contribute, and be mentored). I apologize if this is an improper request for this forum. Many thanks in advance! Malcolm Newsome malcolm.news...@gmail.com <mailto:malcolm.news...@gmail.com> On 09/29/2012 06:16 PM, tutor-requ...@python.org wrote: Send Tutor mailing list submissions to tutor@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/tutor or, via email, send a message with subject or body 'help' to tutor-requ...@python.org You can reach the person managing the list at tutor-ow...@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Tutor digest..." Today's Topics: 1. Re: Lotka-Volterra Model Simulation Questions (Oscar Benjamin) 2. Re: Lotka-Volterra Model Simulation Questions (Alan Gauld) 3. Re: Lotka-Volterra Model Simulation Questions (Oscar Benjamin) 4. Re: Lotka-Volterra Model Simulation Questions (Brett Ritter) 5. Re: generic repr method? (Oscar Benjamin) -- Message: 1 Date: Sat, 29 Sep 2012 22:20:46 +0100 From: Oscar Benjamin To: Jim Apto Cc: tutor@python.org Subject: Re: [Tutor] Lotka-Volterra Model Simulation Questions Message-ID: Content-Type: text/plain; charset="iso-8859-1" On 28 September 2012 21:32, Jim Apto wrote: Hello folks, I'm relatively new to python, and was asked to program a lotka-volterra model (predator and prey relation) simulator. The program basically will basically have a menu that takes user input, collect data, and then create a graph. Currently i've been working on the simulator section; I can't seem to get the lists right. Jim, I apologise if the responses to your original post seem to have gotten distracted from the problems you're having. Also I'm sorry if my first post was a bit abstract. Have the responses so far been helpful? Oscar -- next part -- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/tutor/attachments/20120929/ac95aa50/attachment-0001.html> -- Message: 2 Date: Sat, 29 Sep 2012 22:57:09 +0100 From: Alan Gauld To: tutor@python.org Subject: Re: [Tutor] Lotka-Volterra Model Simulation Questions Message-ID: Content-Type: text/plain; charset=UTF-8; format=flowed On 29/09/12 11:42, Steven D'Aprano wrote: On 29/09/12 19:16, Alan Gauld wrote: I did say I had no idea about the original algorithm so yes, if the variable names are industry standardised and the people working with the code are familiar with them then it may be better to stick with them, As to using short names to keep things on a single line, there is a huge body of research in Comp Science that shows that meaningful names outweigh single line expressions every time in terms of... Yes, but "meaningful names" is relative to the reader, Absolutely, see the first para above. This latter comment was explicitly in response to the snipped (by me) context: "Also there are good reasons for using short names in equations. It makes it much easier to see the whole equation at once, which makes it easier to understand the equations and easier to check your code. If you make the variable names too long, even simple equations like these will have to split over several lines and be more difficult to read/check." To a mathematician, "pi" or "?" is meaningful, and "constant_ratio_of_diameter_to_circumference" would be much harder to read. Totally agree. My point is that we should not choose short names just to keep an expression on a single line. The evidence suggests that the advantages of longer names outweigh the advantage of a single line. But in the cases here where single letters evidently have expressive power in their own right the familiar term is preferable over a longer descriptive name. Of course, care is needed when splitting an expression over multi lines to keep the readability so if the terms can be naturally split by operator then that's the place to split them. But this is the same in written math too. (Most of the equations I remember reading from my quantum mechanics days were split over at least 3 lines... trying to force them into a single line would not have made them any more palatable!) p = m*v*(1-(c/v)**2)**-0.5 they aren't likely to be much enlightened by: momentum = res
