Re: [Edu-sig] probability & simulation
2009/2/6 michel paul : > Warren, > > Your book looks great! I'd be interested in seeing the rest of it. Yeah, > we ended up discussing how to represent a deck of cards in class as well. > One of the kids got inspired while creating the dice simulation and emailed > me asking how to do something like that. So I was really glad to see this > start growing organically. We haven't discussed classes previously, as that > would REALLY have scared them off, so I just had him continue at the level > of simple lists, thinking of cards as simple ordered pairs: > suits = ['S', 'H', 'D', 'C'] ranks = ['A', 2, 3, 4, 5, 6, 7, 8, 9, 10, 'J', 'Q', 'K'] deck = [(rank, suit) for suit in suits for rank in ranks] shuffle(deck) hand = [deck.pop() for card in range(5)] > Good stuff. I'm always tempted to have 'S','H','D','C' replaced by the actual symbols (DejaVu font?), keeping the quote marks as these symbols don't qualify as identifiers, only strings. Here's the relevant page from the Unicode charts. http://unicode.org/charts/PDF/U2600.pdf Let's see what I can do with Python here... >>> import unicodedata >>> heart = chr(0x2665) >>> unicodedata.name(heart) 'BLACK HEART SUIT' I thought hearts were red... I've uploaded a screen shot using these characters in IDLE/Py3K: http://www.flickr.com/photos/17157...@n00/3259871142/ Also, I've finally gotten around to getting my I Ching stuff ported to a Google appengine: http://osgarden.appspot.com Lots of Chinese characters, though not top-level (this is Python 2.5 anyway -- see About page for source). Yes, I use Justin's PyFontify with py2html, colorize code on the fly (had to modify py2html a little). > He played around with this and really got into it. Good news! It's amazing > how much you can do in a simple interactive way with Python. I mean, this > LOOKS like what you do with a deck! But I did try to sow some seeds by > mentioning how you could accomplish even more by thinking in terms of > functions and classes. > > - Michel Yes, REPL is what kids like, though they don't call it REPL (read, evaluate, print loop -- what the interpreter does). I might try EDSL for "eat, digest, say loop" -- you could think of others. In the 1980s the paradigm with BASIC etc. was "write a little program and prompt yourself for inputs" (ala raw_input), but it's easier at first to just work in a session, more like in Logo and APL, cluttering up the workspace (i.e. __main__) with all kinds of remembered stuff. Play around, then cut and paste we you want to keep for next time, some exceptions and debugging already happening interactively. We don't start by writing then running programs, we start by talking to the interpreter, importing existing libraries, poking around. When we we start saving stuff, we think of our first files more like the math library, or string, i.e. a box of tools that we use directly. The math module has no raw_input prompts -- that'd be silly. So our first saved .py files aren't "programs", they're "modules". They may have unit tests or doc tests, should at least have documentation of some kind, but there's no need for a main() or any unifying structure. It's not a "script", it's a "bag of useful things" (a namespace). Some functions, some classes, even some constants maybe... KIrby ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] probability & simulation
Warren, Your book looks great! I'd be interested in seeing the rest of it. Yeah, we ended up discussing how to represent a deck of cards in class as well. One of the kids got inspired while creating the dice simulation and emailed me asking how to do something like that. So I was really glad to see this start growing organically. We haven't discussed classes previously, as that would REALLY have scared them off, so I just had him continue at the level of simple lists, thinking of cards as simple ordered pairs: >>> suits = ['S', 'H', 'D', 'C'] >>> ranks = ['A', 2, 3, 4, 5, 6, 7, 8, 9, 10, 'J', 'Q', 'K'] >>> deck = [(rank, suit) for suit in suits for rank in ranks] >>> shuffle(deck) >>> hand = [deck.pop() for card in range(5)] He played around with this and really got into it. Good news! It's amazing how much you can do in a simple interactive way with Python. I mean, this LOOKS like what you do with a deck! But I did try to sow some seeds by mentioning how you could accomplish even more by thinking in terms of functions and classes. - Michel On Fri, Feb 6, 2009 at 9:21 AM, Warren Sande wrote: > Michel, > > Sounds like you caught their interest, which is great. I have a chapter on > probability and simulation in my book, "Hello World! Computer Programming > for Kids and Other Beginners". It talks about simulating dice, coins, and a > deck of cards. In the second half of the chapter we make a Crazy Eights > card game (text-based). I've attached a preview of the chapter if you want > to have a look. Keep in mind that this is one of the later chapters, and we > have already covered the basics like loops, lists, objects, etc. > > By the way, the book has had some delays in production, but it should be > out in the next few weeks. > > Regards, > Warren Sande > > > -- > *From:* michel paul > *To:* "edu-sig@python.org" > *Sent:* Thursday, February 5, 2009 1:34:49 PM > *Subject:* [Edu-sig] probability & simulation > > We began a unit in math called 'Probability and Simulation'. The students > of course have to solve many typical problems involving dice and coins. > This provided a perfect opportunity for incorporating Python in a way that > didn't freak the kids out. Remember, I have been trying to weave Python > into a math environment where programming is seen as something alien and > scary. Bizarre. The 'choice' function in the random library provides an > excellent way to create all kinds of simulations very easily. I used this > as an example in class: > > >>> coin = ['Heads - I win', 'Tails - you lose'] > > >>> tosses = [choice(coin) for toss in range(1000)] > > It was great. Very easy to understand. This combined with the 'count' > method in a list, and I could go ahead and assign them a little HW project > to create a frequency table for throwing 2 dice 10,000 times. I told them > to just experiment, copy and paste their Shell session and email it to me. > It worked very well. Even a lot of the kids who have been resistant to this > Python stuff could handle it. Didn't require having to write functions - > purely interactive. > > Then the next day we explored tetrahedral and other kinds of dice. > > Very simple, and it seemed to work well. There's a section at the end of > the chapter that describes creating simulations using BASIC. Ha! We did > this on the very first day! > > - Michel > ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Attribute Lookup Order
About my message: >> ... Nickel summary, lookup order is not dirt simple, and reading >> and writing work differently. David MacQuigg wrote: Maybe I'm missing some subtleties, but it still seems simple to me. > An attribute is looked up in the order object -> class -> superclasses, > *UNLESS* that attribute happens to be a property of the class The subtleties involve the difference in the lookup order between read-only properties and properties with a write method. ... class Rectangle(object): def __init__(self, width, height): self.width = width self.height = height #self.area = width * height def getArea(self): return self.width * self.height ... Written in later versions of Python (2.5 and up) as: class Rectangle(object): def __init__(self, width, height): self.width = width self.height = height # self.area = width * height @property def area(self): return self.width * self.height --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Attribute Lookup Order
>And I just noticed a great thread on comp.lang.python addressing the >exact lookup order for obtaining attributes most recent post this >morning. The Thread Title is "Understanding Descriptors", >Brian Allen Vanderburg II asked the initial question, and Aahz and >Bruno Desthuillers came up with a thorough answer. >I'll put a link here, but it may wrap nastily. Nickel summary, lookup >order is not dirt simple, and reading and writing work differently. > >http://groups.google.com/group/comp.lang.python/browse_thread/thread/a136f7626b2a8b7d/70a672cf7448c68e Maybe I'm missing some subtleties, but it still seems simple to me. An attribute is looked up in the order object -> class -> superclasses, *UNLESS* that attribute happens to be a property of the class. The purpose of properties is to over-ride direct access to attributes, and substitute your own getters and setters with whatever robustness is appropriate. Say you have a class Rectangle(object): def __init__(self, width, height): self.width = width self.height = height self.area = width * height and you find your students are changing the width and height parameters, but forgetting to change area. The Java guys will say we should never have written such fragile code, but that is the beauty of Python. We can write something simple, and add the robustness later. class Rectangle(object): def __init__(self, width, height): self.width = width self.height = height #self.area = width * height def getArea(self): return self.width * self.height area = property(getArea) Nothing in the interface changes. Programs dependent on Rectangle will not break, unless they were setting area directly, which they should never have done. Then when they do break, the user will see "AttributeError: can't set attribute", not some subtle error in the data that will screw up later usage. The example is from Martelli's Nutshell, 2nd ed. p.100-101. Quick summary (quoting Martelli): "The crucial importance of properties is that their existence makes it perfectly safe and indeed advisable for you to expose public data attributes as part of your class's public interface." -- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
