[Edu-sig] Topics for CS2
I'm putting together a list of topics for a proposed course entitled "Programming for Scientists and Engineers". See the link to CS2 under http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a follow-on to an introductory course in either Java or C, so the students will have some exposure to programming, but the Java students won't know machine-level programming, and the C students won't have any OOP. For the proposed course, we will use the example programs as a way to introduce these topics. As you can see from the very few links to completed examples, this is just a start. Many of the links are only to discussions on this list, and I really appreciate the suggestions I have received so far. Also, it is far from a representative survey or optimum sample, rather just a random sample of topics that I found interesting. Some of the topics may be out of reach for students at this level, but that is the challenge. Figure out a way to present a complex or theoretically difficult topic in a way that is simple and intuitive and will whet the students appetite for further study. Additional suggestions are welcome. -- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
I've added a few more topics to http://ece.arizona.edu/~edatools/CS2/P4SE.txt, including Black Hole, and Wave-Particle Paradox. Any physicists on the list? I'll do the programming if you can advise me on the physics. H Bomb - start with a bowling ball of LiDT. Squeeze til it goes boom. How much compression is needed? Try smaller balls. Black Hole - start with a bowling ball of neutrons. Squeeze til it collapses. How big is the black hole (the radius at which photons get sucked in)? Wave-Particle Paradox - two detectors with equal probability of detecting any particle from a specific source. Prior to detection, the particle exists only as a wave function with equal intensity at both detectors. When the particle appears at detector A, how does detector B know instantly not to detect the same particle? Model the problem with two slits generating an interference pattern on a screen. Slow the simulation down until you can observe individual particles. Make sure you delete the wave, once its particle has been detected. That avoids the wave-particle problem, at least in the virtual reality of your simulation. Could the universe be a computer, and all we see of it is a virtual reality? The gods who wrote the program had everything worked out except the problem of what happens to the wave after it turns into a particle. So they just added an instruction to delete the wave. That seems to me more plausible than an infinite number of parallel universes, or the crazy story about Schrodinger's cat being nothing but a wave function that decides if it is dead or alive only when the box is opened. What about the guy opening the box? Is he also a wave function, waiting for someone to open the door to the lab? -- Dave At 04:09 PM 1/15/2009 -0700, David MacQuigg wrote: >I'm putting together a list of topics for a proposed course entitled >"Programming for Scientists and Engineers". See the link to CS2 under >http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a >follow-on to an introductory course in either Java or C, so the students will >have some exposure to programming, but the Java students won't know >machine-level programming, and the C students won't have any OOP. For the >proposed course, we will use the example programs as a way to introduce these >topics. > >As you can see from the very few links to completed examples, this is just a >start. Many of the links are only to discussions on this list, and I really >appreciate the suggestions I have received so far. Also, it is far from a >representative survey or optimum sample, rather just a random sample of topics >that I found interesting. Some of the topics may be out of reach for students >at this level, but that is the challenge. Figure out a way to present a >complex or theoretically difficult topic in a way that is simple and intuitive >and will whet the students appetite for further study. > >Additional suggestions are welcome. > >-- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
Hi David --
I've been looking at your PythonOOP.
Why use classes? All programming aside, I think it's a fairly strong
grammatical model of how people think, basically in terms of
noun.adjective (data attribute) and noun.verb() (callable method).
All talk of computer languages aside, we're very noun-oriented, think
in terms of "things" and these things either "are" or "have"
attributes and "do" verby stuff.
OOP is about making the language talk about the problem domain, help
us forget that under the hood nightmare of chips and registers,
needing to allocate memory... all that stupid computer stuff that
nobody cares about (smile).
Of course I like your nomenclature of a Cat inheriting from Animal as
I'm always tying "hierarchy" back to "zoology" and "taxonomy" as those
were original liberal arts tree structures (class hierarchies,
kingdoms, domains, namespaces). We like "astral bodies" subclassed
into stars, planets, planetoids (like Pluto), and moons. We like
"Reptiles" including "Snakes" which of course includes "Pythons"
(everything is a python in Python, i.e. an object with a __rib__
cage).
Having a Dog and a Monkey motivates why ancestor classes are
important: generic shared stuff, like digestion, might be handled in
a shared eat() method, each with its own self.stomach of course. With
a younger set (pre-college), those parentheses connote lips, with args
as oral intake. In the class of classes though... we give birth.
Per a recent PPUG, I'm these days thinking to use a collections.deque
for my digestive tract maybe:
>>> class Animal:
def __init__(self):
self.stomach = deque()
def eat(self, item):
self.stomach.append(item)
def poop(self):
if len(self.stomach)>0:
return self.stomach.popleft()
>>> zebra = Animal()
>>> zebra.eat('straw')
>>> zebra.stomach
deque(['straw'])
>>> zebra.poop()
'straw'
>>> zebra.stomach
deque([])
>>>
Some will want to say digestive_tract instead of stomach.
Now you can develop your Dog and Cat, inheriting eat() and __init__
from Animal, yet each subclass providing its own __repr__ methods.
"Hello world, I'm a Cat at %s" % id(self). Yes, you could make the
__repr__ invoke __class__.__name__ and share it -- show that later
?
>>> class Animal:
def __init__(self):
self.stomach = deque()
def eat(self, item):
self.stomach.append(item)
def poop(self):
if len(self.stomach)>0:
return self.stomach.popleft()
def __repr__(self):
return "I'm a %s at %s" % (self.__class__.__name__, id(self))
>>> class Dog(Animal):
pass
>>> class Cat(Animal):
pass
>>> thing1 = Dog()
>>> thing2 = Cat()
>>> thing1
I'm a Dog at 138223820
>>> thing2
I'm a Cat at 138223852
Students see how inheritance means specializing as you go down the
tree (consistent with most introductory treatments).
Your spin seems to tilted towards Cats with not enough other
subclasses of Animal to make inheritance seem all that necessary.
Your ancestor is mostly for "herding cats" (counting instances), isn't
so much a "blueprint" for different subclasses of the Animal idea
(aardvark versus eel).
More generally I think using an ancestor class to do instance counting
is a little on the "too difficult" side for a core introductory
running example. It leads you to introduce an interception of __del__
as your first example of operator over-riding. This seems rather
unpythonic, as the __del__ method is rather rarely intercepted,
compared to say __set__ and __get__ (per Alex Martelli in this lecture
@ Google: http://controlroom.blogspot.com/2009/01/oop-in-hour.html
).
I was also struck by how often you compare classes to modules (modules
in Chapter 16 right?), suggesting a Perlish upbringing -- as did your
suggestion to use '_' in place of 'self' for "maximal uncluttering"
(paraphrase).
When Perl decided to make the leap to OO, it was "the module" that got
blessed for this purpose yes? Are you a closet Perl Monger then?
I notice you tend to favor your private terminology and don't resort
to the CS vocabulary as often, e.g. "polymorphic" and "polymorphism"
are not included. If you're wanting your students to gain fluency
with the surrounding literature, I think at least that one deserves
more focus, in conjunction with inheritance.
I think the a first class could be all data (like a C struct). Like,
this example says a lot:
>>> class Foo:
bar = 1
>>> f = Foo()
>>> g = Foo()
>>> f.bar = 1
>>> f.bar = 2
>>> g.bar
1
>>> f.bar
2
>>> f.__dict__
{'bar': 2}
>>> g.__dict__
{}
>>> g.bar
1
however once you start adding methods, I don't think postponing the
appearance of __init__ for so long is a good idea. I would focus on a
Dog and a Cat (or any other two animals), both with __init__
constructors and eat methods, then (as a next step) introduce
Re: [Edu-sig] Topics for CS2
Hi Kirby, Many thanks for the thoughtful review of my PythonOOP chapter. I especially like the suggestions to put more emphasis on the role of over-rides in *specializing* the behavior of subclasses, and to at least mention commonly-used CS terms like "polymorphism". I'll keep your suggestions for the next time I do any revisions on this chapter. If you or anyone else wants to make more extensive modifications, target a different audience, etc., I'll be glad to work with you. No reason we can't have multiple versions targeted to different groups. There may be some misunderstanding as to my purpose in writing this chapter. It is not a CS1 introduction to OOP. I would recommend Zelle or Goldwasser for that. It was written before those texts, and specifically for engineers who already know some programming, understand very well the need for modular design (no need for motivation of OOP), and who have learned Python up through chapter 18 of Lutz and Ascher (no need to explain __notation__). It could be an alternative, or a supplement, to the OOP chapters in L&A. It could also be part of the CS2 class I am now proposing, for students who already know Java or C. Some of my choices on what topics to emphasize may be different. These choices were based on my own experience, which may be different than others, and is certainly different from those who have a less pragmatic approach to languages. Thus, I have relegated operator over-riding to "advanced topics" because of my perception that it will be used less often than say, static methods, which I have included in my first large example. I use static methods frequently. They are now (as of version 2.4) more "pythonic" than when this chapter was written, so I feel I made the right choice. If my Animals class hierarchy seems artificial, it may be because I tried to illustrate everything I considered important, and do it in the smallest example that would still be clear. The comparison of classes to modules is not motivated by any affinity to Perl. What little I know of Perl, I don't like. Rather, it is part of an answer to the question "Why do we need classes?" Modules are the closest thing to classes as a unit of encapsulation. With a simple function, you could generate instances of modules as easily as instantiating objects from classes. You could even change the language slightly, and allow multiple modules per file. As for making OOP a "revelation", I think that is the wrong way to teach it, especially for non-CS students. I much prefer to treat it as just another way to encapsulate pieces of a program, a way that is very natural when you are modeling objects in the real world, and can be beneficial even when there is no parallel in the real world - the benefit flowing from the extra flexibility you have in encapsulation. That is something all engineers will understand. The "revelation" approach completely turned me off when I first read about OOP in the early 90's. As a skeptical engineer, I was left with the impression that OOP, polymorphism, etc., was a pile of hype, and there was nothing there I couldn't do in FORTRAN, BASIC, or C. It wasn't until I started using Python in 2002, that I saw the benefits. I like that Python doesn't mystify OOP, or push it the way Java does, but just makes it a natural thing to do. Again, if anyone wants to modify this document for their own purposes, I'll be glad to help. -- Dave At 08:21 PM 1/17/2009 -0800, kirby urner wrote: >Hi David -- > >I've been looking at your PythonOOP. > >Why use classes? All programming aside, I think it's a fairly strong >grammatical model of how people think, basically in terms of >noun.adjective (data attribute) and noun.verb() (callable method). >All talk of computer languages aside, we're very noun-oriented, think >in terms of "things" and these things either "are" or "have" >attributes and "do" verby stuff. > >OOP is about making the language talk about the problem domain, help >us forget that under the hood nightmare of chips and registers, >needing to allocate memory... all that stupid computer stuff that >nobody cares about (smile). > >Of course I like your nomenclature of a Cat inheriting from Animal as >I'm always tying "hierarchy" back to "zoology" and "taxonomy" as those >were original liberal arts tree structures (class hierarchies, >kingdoms, domains, namespaces). We like "astral bodies" subclassed >into stars, planets, planetoids (like Pluto), and moons. We like >"Reptiles" including "Snakes" which of course includes "Pythons" >(everything is a python in Python, i.e. an object with a __rib__ >cage). > >Having a Dog and a Monkey motivates why ancestor classes are >important: generic shared stuff, like digestion, might be handled in >a shared eat() method, each with its own self.stomach of course. With >a younger set (pre-college), those parentheses connote lips, with args >as oral intake. In the class o
Re: [Edu-sig] Topics for CS2
On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg wrote: <<>> [ watching Obama motorcade on CRT to my left, typing to LCD on my laptop ] > There may be some misunderstanding as to my purpose in writing this chapter. > It is not a CS1 introduction to OOP. I would recommend Zelle or Goldwasser > for that. It was written before those texts, and specifically for engineers > who already know some programming, understand very well the need for modular > design (no need for motivation of OOP), and who have learned Python up > through chapter 18 of Lutz and Ascher (no need to explain __notation__). It > could be an alternative, or a supplement, to the OOP chapters in L&A. It > could also be part of the CS2 class I am now proposing, for students who > already know Java or C. > Probably I was confusing your "module" and "modular" (cite Perl below) in that you relate Objects to both, which of course makes sense, in terms of encapsulated name spaces. Classes, unlike mere modules, have progeny, ancestors, spawn multiple instances of themselves without duplicated more bits than necessary. You're clear about this distinction, which I liked. Your role as the teacher most specializing (customizing) to these students is a good example of how curriculum writing itself has a modular aspect, and a subclassing (tiering) from more to less generalized. You've got a very specific mix in mind, a certain type of sophistication. I likewise have my different biases. On a scale of 1-10, overriding __del__ in the process of doing subclass instance counting in a parent class, is like 8 or 9, especially where you bring __mro__ into it. So yes, I see your desire to include arcana. You're being respectful of your students' already high level of initiation. > Some of my choices on what topics to emphasize may be different. These > choices were based on my own experience, which may be different than others, > and is certainly different from those who have a less pragmatic approach to > languages. Thus, I have relegated operator over-riding to "advanced topics" > because of my perception that it will be used less often than say, static > methods, which I have included in my first large example. I use static > methods frequently. They are now (as of version 2.4) more "pythonic" than > when this chapter was written, so I feel I made the right choice. > I'm inclined to see + and * in a continuum with [] and (), in that the former trigger __add__ and __mul__ whereas the latter trigger __getitem__ and __call__ (or __init__). In other words "operator over-riding" tends to blend in with all manner of syntax-invoked method triggering. The fact that * + and such used to be segregated as "immutable operators" gets forgotten in the rough and tumble. We don't keep quite the same unary / binary fixation either, in that a.__add__(b) is an act of consumption (a eats b, maybe returns c of some type), just as is f(1) an act of consumption (swallowing a name). a * b is a "munch" operation, in that __mul__ (or __rmul__) is getting invoked. In the old days, I tell my students, numbers were stupid, they couldn't do anything, didn't know anything. Operators descended from heaven, like space ships, and caused numbers to be added and multiplied. But in Python, everything is a snake, a live object, including numbers like 1 and 2, and they have knowledge of addition and multiplication "in their bones" (__ribs__). When you go 1 * 2, that's not a space ship, bristling with static methods from on high, from the alien "knows operations" land, that's invoking an innate ability of the integer type. It's a change in gestalt, especially if you start with the old one. > If my Animals class hierarchy seems artificial, it may be because I tried to > illustrate everything I considered important, and do it in the smallest > example that would still be clear. The comparison of classes to modules is > not motivated by any affinity to Perl. What little I know of Perl, I don't > like. Rather, it is part of an answer to the question "Why do we need > classes?" Modules are the closest thing to classes as a unit of > encapsulation. With a simple function, you could generate instances of > modules as easily as instantiating objects from classes. You could even > change the language slightly, and allow multiple modules per file. > I'm biased against modules because I start at the shell and don't care about saving any .py files for awhile, have no interest in anything but the current namespace, like a white board. My simplest unit is the primitive object, like 1 or 'a', an integer or string. We do a dir on both of these, show they "have guts" i.e. are endowed with methods. So a number like 2 is a primitive name space, in containing (encapsulating) a lot of behaviors. Next up, data structures or collections, things like iterables, like lists, tuples. Each supports dot notation to methods, has an interior. With functions, you
Re: [Edu-sig] Topics for CS2
On Tue, Jan 20, 2009 at 8:45 AM, kirby urner wrote: > On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg > wrote: > > <<>> > > [ watching Obama motorcade on CRT to my left, typing to LCD on my laptop ] > >> There may be some misunderstanding as to my purpose in writing this chapter. >> It is not a CS1 introduction to OOP. I would recommend Zelle or Goldwasser >> for that. It was written before those texts, and specifically for engineers >> who already know some programming, understand very well the need for modular >> design (no need for motivation of OOP), and who have learned Python up >> through chapter 18 of Lutz and Ascher (no need to explain __notation__). It >> could be an alternative, or a supplement, to the OOP chapters in L&A. It >> could also be part of the CS2 class I am now proposing, for students who >> already know Java or C. >> > > Probably I was confusing your "module" and "modular" (cite Perl below) > in that you relate Objects to both, which of course makes sense, in > terms of encapsulated name spaces. Classes, unlike mere modules, have > progeny, ancestors, spawn multiple instances of themselves without > duplicated more bits than necessary. You're clear about this > distinction, which I liked. > > Your role as the teacher most specializing (customizing) to these > students is a good example of how curriculum writing itself has a > modular aspect, and a subclassing (tiering) from more to less > generalized. You've got a very specific mix in mind, a certain type > of sophistication. I likewise have my different biases. > > On a scale of 1-10, overriding __del__ in the process of doing > subclass instance counting in a parent class, is like 8 or 9, > especially where you bring __mro__ into it. So yes, I see your desire > to include arcana. You're being respectful of your students' already > high level of initiation. > >> Some of my choices on what topics to emphasize may be different. These >> choices were based on my own experience, which may be different than others, >> and is certainly different from those who have a less pragmatic approach to >> languages. Thus, I have relegated operator over-riding to "advanced topics" >> because of my perception that it will be used less often than say, static >> methods, which I have included in my first large example. I use static >> methods frequently. They are now (as of version 2.4) more "pythonic" than >> when this chapter was written, so I feel I made the right choice. >> > > I'm inclined to see + and * in a continuum with [] and (), in that the > former trigger __add__ and __mul__ whereas the latter trigger > __getitem__ and __call__ (or __init__). > > In other words "operator over-riding" tends to blend in with all > manner of syntax-invoked method triggering. The fact that * + and > such used to be segregated as "immutable operators" gets forgotten in > the rough and tumble. > > We don't keep quite the same unary / binary fixation either, in that > a.__add__(b) is an act of consumption (a eats b, maybe returns c of > some type), just as is f(1) an act of consumption (swallowing a name). > a * b is a "munch" operation, in that __mul__ (or __rmul__) is > getting invoked. > > In the old days, I tell my students, numbers were stupid, they > couldn't do anything, didn't know anything. Operators descended from > heaven, like space ships, and caused numbers to be added and > multiplied. > > But in Python, everything is a snake, a live object, including numbers > like 1 and 2, and they have knowledge of addition and multiplication > "in their bones" (__ribs__). When you go 1 * 2, that's not a space > ship, bristling with static methods from on high, from the alien > "knows operations" land, that's invoking an innate ability of the > integer type. > I made a fun cartoon out of the above: http://mybizmo.blogspot.com/2009/01/transitions-of-power.html My more technical argument, about how OO changes our view of operators, in this older paper, where my nouns are quaternions: http://www.4dsolutions.net/ocn/oopalgebra.html Kirby > It's a change in gestalt, especially if you start with the old one. ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
At 08:45 AM 1/20/2009 -0800, kirby urner wrote: >On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg wrote: >> There may be some misunderstanding as to my purpose in writing this chapter. >... > >On a scale of 1-10, overriding __del__ in the process of doing >subclass instance counting in a parent class, is like 8 or 9, >especially where you bring __mro__ into it. So yes, I see your desire >to include arcana. You're being respectful of your students' already >high level of initiation. All this is in the "Advanced Topics" section at the end. I probably should make that a separate chapter to avoid any distraction. The part I expect students at the CS2 level to understand is in the first 12 pages, and that should be free of arcana. ... >But in Python, everything is a snake, a live object, including numbers >like 1 and 2, and they have knowledge of addition and multiplication >"in their bones" (__ribs__). When you go 1 * 2, that's not a space >ship, bristling with static methods from on high, from the alien >"knows operations" land, that's invoking an innate ability of the >integer type. > >It's a change in gestalt, especially if you start with the old one. ... >> As for making OOP a "revelation", I think that is the wrong way to teach it, >> especially for non-CS students. I much prefer to treat it as just another >> way to encapsulate pieces of a program, a way that is very natural when you >> are modeling objects in the real world, and can be beneficial even when >> there is no parallel in the real world - the benefit flowing from the extra >> flexibility you have in encapsulation. That is something all engineers will >> understand. The "revelation" approach completely turned me off when I first >> read about OOP in the early 90's. As a skeptical engineer, I was left with >> the impression that OOP, polymorphism, etc., was a pile of hype, and there >> was nothing there I couldn't do in FORTRAN, BASIC, or C. It wasn't until I >> started using Python in 2002, that I saw the benefits. I like that Python >> doesn't mystify OOP, or push it the way Java does, but just makes it a >> natural thing to do. >> > >Yes, that transition to OOP was upsetting as a paradigm change. I >went through it on the xBase path, following dBase II (derived from >some JPL language) through its winged migration, fork off to Clipper, >FoxPro, buyout by Microsoft and Borland, FoxPro for Windows, Visual >FoxPro. The full OO paradigm came across, unlike for the VB crowd, >who didn't get that until later. This all happened in my little world >*before* I ever wrote a line of Python (plus I got to Java first). >APL was the first computer language I ever learned (loved it), then >FORTRAN (yawn). > >However, the real benefit of OO is it hooks to natural language, where >students in human languages, like Sumerian, like Greek, already know >about nouns, verbs and adjectives as parts of speech. OO is all about >noun.verb() and noun.adjective. Then with have these little cartoons >about sharing pointers (names) to objects and we're done, they're >convinced there's a real grammar here, a logic, and dive in, happy to >still be in the humanities, no talk of "computer hardware" need apply >(though it's handy to have). This isn't "hyping" so much as >"bridging". In industry, it's about town-gown relations, where "town" >is an administrative layer atop cube farmers, and "gown" is IT. With >ORM, we're finally starting to get admin enrolled in seeing it from >IT's point of view, whereas SQL by itself was just not friendly >enough. > >OO makes computing more personable. To have busy administrators see >'self' as like "a little ego with a personal __dict__ clipboard" is >not "dumbing it down" is rather taking advantage of well-worn patterns >in grammar, leveraging what we've already got. It's efficient. Don't >just say "is a", say "I am a". This isn't just cute, it's a >conceptually smart way to think about a hospital, school or airport >(objects all). But that's me to busy administrators, not you to >enrolled electrical engineers. Different audiences = different >patter, we both know that. I think many of us who grew up with the "old gestalt" had a hard time with the transition to OOP. Maybe the old gestalt still includes administrators, but I would be surprised if it includes high-school students. It did include engineering students a few years ago, when we had a junior-level course in OOP taught in Smalltalk, so the students would be forced to break out of their old habits and do everything in the style of OOP. We still have that course, but now the pre-requisite is a course in Java, and it has morphed to more software-engineering and less pounding on the necessity of OOP. It seems that the "new gestalt" should not require breaking old habits. Objects should be introduced early, the noun.verb syntax is simple, and there is little need for motivation, revelation, or elaborate analogies by the time t
Re: [Edu-sig] Topics for CS2
David MacQuigg wrote: I've added a few more topics to http://ece.arizona.edu/~edatools/CS2/P4SE.txt, including Black Hole, and Wave-Particle Paradox. Any physicists on the list? I'll do the programming if you can advise me on the physics. H Bomb - start with a bowling ball of LiDT. Squeeze til it goes boom. How much compression is needed? Try smaller balls. Black Hole - start with a bowling ball of neutrons. Squeeze til it collapses. How big is the black hole (the radius at which photons get sucked in)? Wave-Particle Paradox - two detectors with equal probability of detecting any particle from a specific source. Prior to detection, the particle exists only as a wave function with equal intensity at both detectors. When the particle appears at detector A, how does detector B know instantly not to detect the same particle? Model the problem with two slits generating an interference pattern on a screen. Slow the simulation down until you can observe individual particles. Make sure you delete the wave, once its particle has been detected. That avoids the wave-particle problem, at least in the virtual reality of your simulation. Could the universe be a computer, and all we see of it is a virtual reality? The gods who wrote the program had everything worked out except the problem of what happens to the wave after it turns into a particle. So they just added an instruction to delete the wave. That seems to me more plausible than an infinite number of parallel universes, or the crazy story about Schrodinger's cat being nothing but a wave function that decides if it is dead or alive only when the box is opened. What about the guy opening the box? Is he also a wave function, waiting for someone to open the door to the lab? -- Dave At 04:09 PM 1/15/2009 -0700, David MacQuigg wrote: I'm putting together a list of topics for a proposed course entitled "Programming for Scientists and Engineers". See the link to CS2 under http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a follow-on to an introductory course in either Java or C, so the students will have some exposure to programming, but the Java students won't know machine-level programming, and the C students won't have any OOP. For the proposed course, we will use the example programs as a way to introduce these topics. As you can see from the very few links to completed examples, this is just a start. Many of the links are only to discussions on this list, and I really appreciate the suggestions I have received so far. Also, it is far from a representative survey or optimum sample, rather just a random sample of topics that I found interesting. Some of the topics may be out of reach for students at this level, but that is the challenge. Figure out a way to present a complex or theoretically difficult topic in a way that is simple and intuitive and will whet the students appetite for further study. Additional suggestions are welcome. -- Dave In PythonOOP.doc (page 4) you say: > There are two pieces of "magic" that make line 3 work. First, the > interpreter has to find the method set_vars. It's not in cat2. Then, > the instance cat2 has to be inserted as the first argument to et_vars. > The method is found by a search starting at cat2 ( the instance on > which the method is called ). The search then proceeds to the parent > class, then to the grandparent, and so on up to object, the ancestor > of all Animal classes. In this case, we find set_vars in Cat. For instances of subclasses of object (such as Cat), method lookups start in Cat, not cat2. If you try to set cat2.set_vars, you cannot (because a method is a property stored in he class), and you will try the set method of that property which will fail. Simple class variables are over-ridden by assignments to the instance values, but properties are not. --Scott David Daniels scott.dani...@acm.org the property, ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
Scott David Daniels wrote: I wrote: In PythonOOP.doc (page 4) you say: > There are two pieces of "magic" that make line 3 work. First, the > interpreter has to find the method set_vars. It's not in cat2. Then, > the instance cat2 has to be inserted as the first argument to et_vars. > The method is found by a search starting at cat2 ( the instance on > which the method is called ). The search then proceeds to the parent > class, then to the grandparent, and so on up to object, the ancestor > of all Animal classes. In this case, we find set_vars in Cat. For instances of subclasses of object (such as Cat), method lookups start in Cat, not cat2. If you try to set cat2.set_vars, you cannot (because a method is a property stored in he class), and you will try the set method of that property which will fail. Simple class variables are over-ridden by assignments to the instance values, but properties are not. And then immediately went to make a test case, which failed. Which I should, of course, done before hitting send. I retract my comment and will get back to you when I get my understanding straightened out. --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] Topics for CS2
> I think many of us who grew up with the "old gestalt" had a hard time with
> the transition to OOP. Maybe the old gestalt still includes administrators,
> but I would be surprised if it includes high-school students. It did include
> engineering students a few years ago, when we had a junior-level course in
> OOP taught in Smalltalk, so the students would be forced to break out of
> their old habits and do everything in the style of OOP. We still have that
> course, but now the pre-requisite is a course in Java, and it has morphed to
> more software-engineering and less pounding on the necessity of OOP.
>
Yes, reminds me of the New Math of the 1960s and the subsequent
backlash, teachers bitter about having their authority undermined by
all this newfangled set notation, unions and intersections of this and
that, a lotta b.s. some of 'em thought, made 'em hate Sputnik, all
that bleeping noise.
But then a lot from that era did stick around, a lot of reforms in
early math curriculum writing (e.g. Dolciani). Newer text books
helped glue together our current algebra thru calculus pipeline, which
colleges still treat as a superhighway through admissions, aka ye old
"Calculus Mountain" of Pycon 2008.
Besides just OO, lambda calculus made the leap to machine executable,
with its functional concepts ("big lambda"). Then we've got Haskell
and like that, so it's not like OO is all alone in this brave new
world of executable logics, anticipated by Leibniz, Ada, and Dr.
Vannevar Bush, the latter writing about hypertext and search engines
in the 1940s if not in those terms.
Left behind on the far side of the digital divide were the calculator
crowd with their "white board" logics -- stuff that only "works" on
paper. Mathematica rescued a lot of that stuff, forcing long overdue
house-cleaning.
In the old typography, f(x) is quite ambiguous as it might as well
mean f * x or f eats x.
In Python, those aren't so different, in that __mul__ eats a name as
its argument. a * b and a(b) are really quite similar, in that ()
triggers __call__, just another __rib__, like __mul__.
We think different now, thanks not just to Smalltalk, but to Apple and
NeXT, all helping to make OO real in the workplace.
High schools languish because there's this "you can't make me
attitude" on the part of professionals, who perceive evolutionary
pressures as "other people telling me what to do". Pride gets in the
way. Not saying this is a unique case. We all tend to get stuck in
the mud of our own generation. That's why we've each got this TTL I
suppose, like in tcp/ip -- a sensible design.
As a result of this languishing, many future engineers must do their
serious studying after hours, in cyberspace, where we yak about SQL,
RSA, Unicode, Ruby... -- all "the good stuff" they're likely not
getting from Portland Public (yet).
> It seems that the "new gestalt" should not require breaking old habits.
> Objects should be introduced early, the noun.verb syntax is simple, and there
> is little need for motivation, revelation, or elaborate analogies by the time
> the students get to crafting their own objects. That seems to be the
> approach taken by newer texts, and it would have been beneficial for me also.
> It really wasn't the difficulty of the OOP paradigm that held us back, but
> the awkwardness of the languages, which perhaps created a need to force-feed
> and over-sell the idea of OOP, which turned off pragmatic folks like myself.
> We still have that awkwardness in our intro Java courses, but it seems to
> have been accepted as a minor inconvenience ("Just memorize this stuff, we'll
> explain it later.").
>
An early algebra class, lesson plan:
Ms. Jones shows her students how to use their totatives function to
populate a list with Modulo Numbers. Their "closure checker", written
as a Python generator, inspires discussion about groups.
Use a prime modulus next time, talk about fields.
Source code:
from random import choice
def gcd(a,b):
while b:
a, b = b, a % b
return a
def totatives(n):
return [ x for x in range(1, n) if gcd(x, n) == 1]
class Modulo:
m = 12
def __init__(self, n):
self.n = n % Modulo.m
def __mul__(self, other):
return Modulo(self.n * other.n)
def __eq__(self, other):
return self.n == other.n
def __repr__(self):
return str(self.n)
def closure_checker(pool):
while True:
a = choice(pool)
b = choice(pool)
result = a * b
assert result in pool
yield "%s * %s == %s" % (a, b, result)
>>> from algebra import *
>>> p = totatives(12)
>>> thegroup = [Modulo(x) for x in p]
>>> thegroup
[1, 5, 7, 11]
>>> g = closure_checker(thegroup)
>>> next(g)
'5 * 7 == 11'
>>> next(g)
'5 * 7 == 11'
>>> next(g)
'11 * 11 == 1'
>>> next(g)
'5 * 5 == 1'
>>> next(g)
'7 * 7 == 1'
>>> next(g)
'11 * 7 == 5'
The Modulo class is somewhat subtle in that the self.__dict__ n values
are simply integer type
Re: [Edu-sig] Topics for CS2
On Thu, Jan 15, 2009 at 3:09 PM, David MacQuigg wrote: > I'm putting together a list of topics for a proposed course entitled > "Programming for Scientists and Engineers". See the link to CS2 under > http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a > follow-on to an introductory course in either Java or C, so the students will > have some exposure to programming, but the Java students won't know > machine-level programming, and the C students won't have any OOP. For the > proposed course, we will use the example programs as a way to introduce these > topics. Earth Treasury might be interested in working with you on this, if you are willing to have it distributed under a Free license in multiple languages. We are working on teaching Computer Science ideas in an age-appropriate manner on the OLPC XO starting in third grade, or if possible earlier, using Smalltalk, Turtle Art, Logo, Python, and other powerful tools, and continuing through 12th grade at least. We will also be using the XO's digital oscilloscope capability (Measure Activity) to teach science and engineering. The outline of our project, with the names of our confirmed partners and a few prospective partners we are talking with, is at http://wiki.sugarlabs.org/go/Creating_textbooks. We will have more announcements of partners, resources, projects, and so forth fairly soon. > As you can see from the very few links to completed examples, this is just a > start. Many of the links are only to discussions on this list, and I really > appreciate the suggestions I have received so far. Also, it is far from a > representative survey or optimum sample, rather just a random sample of > topics that I found interesting. Some of the topics may be out of reach for > students at this level, but that is the challenge. Figure out a way to > present a complex or theoretically difficult topic in a way that is simple > and intuitive and will whet the students appetite for further study. > > Additional suggestions are welcome. > > -- Dave > > > ___ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
At 09:33 PM 1/22/2009 -0800, Edward Cherlin wrote: >On Thu, Jan 15, 2009 at 3:09 PM, David MacQuigg wrote: >> I'm putting together a list of topics for a proposed course entitled >> "Programming for Scientists and Engineers". See the link to CS2 under >> http://ece.arizona.edu/~edatools/index_classes.htm. This is intended as a >> follow-on to an introductory course in either Java or C, so the students >> will have some exposure to programming, but the Java students won't know >> machine-level programming, and the C students won't have any OOP. For the >> proposed course, we will use the example programs as a way to introduce >> these topics. > >Earth Treasury might be interested in working with you on this, if you >are willing to have it distributed under a Free license in multiple >languages. No problem. >We are working on teaching Computer Science ideas in an >age-appropriate manner on the OLPC XO starting in third grade, or if >possible earlier, using Smalltalk, Turtle Art, Logo, Python, and other >powerful tools, and continuing through 12th grade at least. We will >also be using the XO's digital oscilloscope capability (Measure >Activity) to teach science and engineering. I could see some of these CS2 programs being useful for high-school students, especially if they have already learned a computer language. No reason they can't be at the same level in programming as college students in the USA. >The outline of our project, with the names of our confirmed partners >and a few prospective partners we are talking with, is at >http://wiki.sugarlabs.org/go/Creating_textbooks. I had no idea these little laptops could run Linux. Cool. -- Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
On Fri, Jan 23, 2009 at 8:44 AM, David MacQuigg
wrote:
<< SNIP >>
> I had no idea these little laptops could run Linux. Cool.
>
> -- Dave
Future tell all journalism needed but there's a lot of RedHat under
the hood, Python too slow for an operating system, an agile, needs an
aquarium to play safe in, with other VHLL friends (high level life
forms... like Squeak, yum).
So yeah, those G1G1 toy-looking toyz are quite the thing to have if
you're a North American, proves you're thinking ahead, some kind of
genius maybe, or at least a blogger of high repute. You'll notice I
milk mine for all its worth ("mooo" says the little xo), plus now I
have two, thanks to Hong Kong connections.
I nominated OLPC's Negroponte for Math Czar in DC, spoofing this
tendency to have a "czar" for everything, starting with that general
for drugs. Either him or Richard Stallman, truly innovative spirits,
very remote from the corrupted text book industries and their
fly-by-night traffic in dead trees (shudder), both pure as the driven
snow.
But then I'm really against stupid top-down curriculum regimes, like
in old Europe. 50 states = 50 laboratories, designed to compete, vie
for leadership, not all toe some party line set in some faraway
swamplands (a wonderful city, spent many years there) -- better to
anchor in Anchorage why not? More fun. Or Hawaii maybe?
Here's da link: http://mathforum.org/kb/thread.jspa?threadID=1889066&tstart=0
My Chicago slides contain pro XO PR, point out that OLPC.xo.pippy
contains Fibonacci's and Pascal's both in its namespace, even if not
in Py3K generator format (OK, so Portland's ahead, what we'd expect
from an open source capital). A core focus of my talk is the purpose
of "lore", not just as idle banter, but as glue for the technical
stuff, an orthogonal axis.
Here's that graph, consider fixed arrow length as representing an
upper limit on bandwidth (in our human subject):
http://www.flickr.com/photos/17157...@n00/3214428790/
(note: "Saxon" refers to this military guy who thought US math
textbooks sucked, created his own, caught on with the home schoolers,
gave 'em an edge on tests, entre to top schools, quite a story, remind
me to say more).
Kirby
>
> ___
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Topics for CS2
Scott David Daniels wrote: Scott David Daniels wrote: I wrote: In PythonOOP.doc (page 4) you say: > There are two pieces of "magic" that make line 3 work. First, the > interpreter has to find the method set_vars. It's not in cat2. Then, > the instance cat2 has to be inserted as the first argument to set_vars. > The method is found by a search starting at cat2 ( the instance on > which the method is called ). The search then proceeds to the parent > class, then to the grandparent, and so on up to object, the ancestor > of all Animal classes. In this case, we find set_vars in Cat. For instances of subclasses of object (such as Cat), method lookups start in Cat, not cat2. If you try to set cat2.set_vars, you cannot (because a method is a property stored in he class), and you will try the set method of that property which will fail. Simple class variables are over-ridden by assignments to the instance values, but properties are not. This should be read/write properties are not. And then immediately went to make a test case, which failed. Which I should, of course, done before hitting send. I retract my comment and will get back to you when I get my understanding straightened out. 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 --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
