[Edu-sig] Cute link for the Willamette CS Department
You'll enjoy this: http://norvig.com/21-days.html --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Naming in Python
Kirby Urner wrote: [ lots of fun and good stuff ] class Function: def __init__(self, f): self.f = lambda x: f(x) ... Here you missed a simplicity bet (one of my two big pet peeves): class Function: def __init__(self, f): self.f = f ... For the curious, the other peeve is: def function(... if expression: return True else: return False instead of: def function(... return expression --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Computer-Adaptive Test of Python
damon bryant wrote: ... experiment[ing] with the concept of an online computer-adaptive test, ... Take a look at research done in the 1970s at the Institute for Mathematical Studies in the Social Sciences (a Stanford University research institute). They did a lot of strong work on keeping the student at 80% correct in several kinds of subject areas. The learning rate they found on those systems was substantially greater than one grade-level per year without extra contact hours. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Best approach to teaching OOP and graphics
Linda Grandell wrote: How about making a small graphics library that has Shape objects. You create a shape object and manipulate it's attributes such as position, color, size, numOfVertices (triangle, square, pentagram), etc. Then you can teach subclassing a shape object, and finally making your own from scratch. PyGame of course is a great environment to build such a thing. This sounds like a good idea. I was thinking about using the pygsear package first, mainly because I then would have ready-made material and examples to start from. The course starts in three weeks, so I am not really spoiled with time here. However, your suggestion should not take that long to implement. I will put it on my list of possible alternatives. Take a look at VPython. It is the simplest to grasp how to put a few things on the screen; it has a nice small set of 3-D primitives, and a quick intro to get a small display going. Really easier than most 2-D packages I've seen to start with, and you get to roll it around. If you are at PyCon, talk to Kirby about his experiences using it in his classes. /Linda -- -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Graphical Programming and OOP
Linda Grandell wrote: The more I teach, the more I come to realize that programming might be one of the most challenging subjects for teachers. Have you read Dijkstra's ACM article The Cruelty of Teaching Computer Programming? It gives name to many of the tough problems that make the effort less than simple. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Integration correction
[EMAIL PROTECTED] wrote: From: Kirby Urner [EMAIL PROTECTED] @simpson def g(x): return x*x g(0, 3) 9.0036 My resistance to decorators is not unrelated to the fact that I don't seem capable of getting my mind around them. I do find it quite disconcerting that the arguments g is expecting cannot be ascertained in the normal manner - that is by looking at g for the arguments it is expecting. Ouch, ouch, ouch. There is a difference between generators and functional programming. This example is, I think a bit of a misuse of generators: you should be producing the same function somehow. So generators that keep a cache of answers to slow questions, generators to do logging, and such like make a lot of sense to me. I think the example above is better written as: def g(x): return x*x f = simpson(g) f(0, 3) It is an example of functional programming, and generators are always about functions of functions, but they are not always the right way to express it. Functional programming is often hard to wrap your head around. I am not sure generators add to the problem, but generators just cannot be used in anything but a functional way. I *particularly* dislike decorators in the context of teaching/learning. Something that is relatively straight forward as executable pseudo-code becomes fancy/schmancy programming. Well, one natural progression is values, expressions, variables, functions, then one of recursion, objects, or functions of (and returning) functions. I would think generators belong fairly soon after functions of functions. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Re: Integration correction
Kirby Urner wrote: Again, I think you're probably right, that this particular example is perverse. Edu-sig is a scratch pad for bad ideas too. :-D Sorry, Kirby, I see we all seemed to jump on top of you here. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python for CS101
Dan Crosta wrote: the current language (at Swat, currently C, but transitioning to Java) is used in the intro course? Certainly C at least is a language worth knowing as a computer scientist, but need it be introduced to students who've never used anything other than Windows or Mac OS? Probably not. Are there any good reasons why such a low-level language ought to be taught in the intro-intro course, other than that the faculty probably know it pretty well? I see it fitting in nicely as a mid-level class, or even as a task students take on when in a class that requires knowing C (my experience has been that picking up a new programming language is time consuming but not that difficult). The only virtue I see to starting in C is similar to my start in assembly years ago: to know what runs efficiently on a computer. C took the place of most assembly language programming some time ago (there are still some things better done in assembly, but less now than before). The advantage to starting in machine (in fact I did; assembly came in the second course) was that I never believed there were magic programmers that did stuff mere mortals did not. It would be a shame to lose this no magic here by side-tracking C to an extended exercise. I'd put it in an architecture class, perhaps. At least C (and preferably some native assembly) code should be early in a curriculum, but certainly CS101 is not the time. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Programming Exercises
Chuck Allison wrote: Hello edu-sig, Does anyone know of a good source of programming exercises/projects to use when teaching Python to people who already know another language? Solutions don't need to be available - I just need some good sample programming assignments. Thanks. You need to tell us what yu are interested in / would like to do. Do you want to find eigenvectors? Do you want to do GUI work? -- -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Programming Exercises
Chuck Allison wrote: Hello Scott, Thursday, May 26, 2005, 1:55:15 AM, you wrote: SDD Chuck Allison wrote: Hello edu-sig, Does anyone know of a good source of programming exercises/projects to use when teaching Python to people who already know another language? Solutions don't need to be available - I just need some good sample programming assignments. Thanks. SDD You need to tell us what yu are interested in / would like to do. SDD Do you want to find eigenvectors? Do you want to do GUI work? Good question. Mostly I need general assignments (using sequences, mappings, text processing, basic OO, launching processes for testing, etc.), but also simple mail apps and basic COM (like processing Microsoft Word docs). No higher math. Some basic GUI ones would be nice too (will be using wxPython). Thanks! First, do the Python tutorial if you have not. Try following Dive Into Python if it meets your tastes. For text processing: Create or obtain a couple of plain ASCII texts. One should be short for testing and development, and another long for fun and production. Look to Project Gutenberg if you don't have anything long yourself. Make a concordance (words to position) that you can save and restore w/o re-counting your text. Find the N (50 for big) most frequent words used. Once you have all that working, figure out how to show all instances of a selected word in context. For extra credit, words, sorted by frequency or alphabetically (button selectable) presented on a wx window that show your word in context when clicking on a word. That should hold you for a day or two. --- My bias is to go test-forward, so (if you want to try that) here is a start (a first test to pass). Most of this is boilerplate, look at the body of test_words to see the only actual test here. Create a test_wordy.py file as so: import unittest from StringIO import StringIO import wordy # the module you are actually testing class TestWords(unittest.TestCase): def test_words(self): source = StringIO(a test) self.assertEqual(['a', 'test'], list(wordy.aswords(source))) if __name__ == '__main__': unittest.main() Now, when you run python on this file you will get a failure. The first one is that wordy.py doesn't exist. Keep fixing until your test passes. Then add tests for new behavior, watch them fail, and fix the source until it works. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Another loop around
Kirby Urner wrote: Arthur: For the largest majority of students - it seems clear to me - asking them to learn to program, in Python or any other language for that matter, would be the single *hardest* thing they have been asked to do in their academic careers. You (Arthur) should read Djistra's On the Crulety of Teaching Computer Programming (or is that Computer Science?) -- Communications of the ACM, I'm not quite sure when (I'd guess within the last five years). He essentially agrees with you as to a computer science curriculum for undergraduate majors. ... def f(x): return x*x points = [(x, f(x)) for x in range(-10,11)] print points plot(points) Is that much harder than ordinary math? Using Python as an interactive workspace. Programming to learn. A friend that I've helped learn to program has said that learning to program improved his ability to think about complicated things. Now this effect is an old math effect; I expect that it is much about how to think rigorously. The nicest thing about programming is that the rigor is enforced for a comprehensible reason: the machine follows your orders. Enough people get frustrated at math simply because it is far from obvious when you have enough rigor and when you don't. Math, to them, seems like a game with a few rules missing. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] A case against GUIs in intro CS :-)
Arthur wrote: The author communicates respect for his audience. He says things once. Even hard things. It doesn't mean he expects me to get it on reading it once, but we understand each other I think - there is nothing stopping me from reading it five or six times if I need to. Him repeating himself is not going to help - because he has already said it the best way he could find to say it. Saying it a second time, he could only be saying it a second best way. Some day when you are feeling ambitious, take a gander at Knuth's The Art of Computer Programming. Reading Knuth is hard; he writes well but succinctly. A twenty-page assignment is a huge chunk of text. But none of is wrong, or hand-holding, or repetitious. The one thing you might not expect is that the answers to exercises sections includes ideas only mentioned in that section. I think of reading TAOCP as reading poetry; you read a bit, reflect a lot, and then read a bit more. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] A case against GUIs in intro CS :-)
Arthur wrote: I don't remember SQL and database ever coming up here Where does it fit into the CS curriculum? It is typically its own course (it takes a completely different attitude than another programming language). Most programmers pick it up after school. Usually they don't want to understand, but just have to get this coded. There are too many texts that cater to that attitude, to the detriment of the consumer. This attitude leads to bad (inefficient), product-specific SQL. The best texts I've found for DB for the programmer are Joe Celko's books; he has a good blend of practical and enough theory to steer it. He is also one of the few practical programming authors to write about how to write in SQL without picking a single vendor and teaching you how to use their product. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Explaining Classes and Objects
Kirby Urner wrote: Based on my working with Bernie, I think it's helpful to start early with the class/object distinction rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw() A useful note here: all programmers are _used_ to using objects: The file for I/O is an OS-defined object (without the nifty syntax in such cases). OO provides (A) a way to define abstractions that behave like the file abstraction yourself, and (B) a way to (at least sometimes) define an abstaction that is just like that other abstraction except. Until you have A, B doesn't make sense. B is hard to teach in that you need to go slowly -- the changes made by inheritance take a while to get. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
): self.perimeter = self.a + self.b + self.c s = 0.5 * self.perimeter self.area = math.sqrt(s * (s - self.a) *(s - self.b) * (s - self.c)) self.A = math.acos((-self.a**2 + self.b**2 + self.c**2) / (2.0 * self.b * self.c)) self.B = math.acos((self.a**2 - self.b**2 + self.c**2) / (2.0 * self.a * self.c)) self.C = math.acos((self.a**2 + self.b**2 - self.c**2) / (2.0 * self.a * self.b)) --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Arthur wrote: As an API matter, I find myself liking the clue that () provides as to whether one is accessing something designed be determined dynamically. In general I agree with that sentiment. I find myself leaning towards the option of making the use of properties go away in PyGeo. If you want to keep anything as properties, I'd keep the ones those properties with the least dynamic nature. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Chuck Allison wrote: Since this discussion has swerved a little, I'd like to pose a query. I've been using patterns since 1995 and am teaching a course starting Wednesday (a full semester course) on Design Patterns using the Heads First book. My query: do you have any ideas you might proffer for programming assignments? I'd like to give a handful of programming assignments throughout the semester that aren't as short and cutesy as what's in the book. Any ideas would be greatly appreciated! What subject and to whom? If programming and/or CS, I'd be tempted to give a chain of assignments where the requirements swerve, showing the value of malleability in code design. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Arthur wrote: ... more to my point is the fact that I don't expect my programming language to solve the problem of decoupling my API from my code. Because I don't expect it to be a solvable problem. I don't know if I'm beating a dead horse, but I don't claim properties solves the problem of decoupling an API from its current implementation. I do claim it provides another tool to express a properly decoupled API. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design patterns
Chuck Allison wrote: My syllabus is at http://uvsc.freshsources.com/html/cns_439r.html. One thing I've always wanted to see if the class is small enough: Groups shuffling other group's previous layers, and providing feedback (but not grades) to the original group. It is always a shock the first time you see someone else trying to use code you thought was clear. The reason for no grades is to eliminate the grade race gaming among groups. A good MVC exercise is a fairy chess (e.g. kriegspiel) server and clients. A sample sequence of constraints: (1) single game (2) single game with observers (3) game with observers w/o enough info to cheat by players. (4) multi-game server. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
Kirby Urner wrote: So I find that rejecting it as naïve is fundamentally unresponsive. Art However in this case I don't think your views were rejected as naïve. On the contrary, your views permeated a sophisticated discussion of use cases, and design patterns more generally (s'been a rich thread) plus Scott sort of liked your using () to connote dynamism (I didn't). This is close to what I meant. I dislike properties that don't behave as if they were attributes. That is, I'd like two accesses to the same property of a particular object to return the same value until the object has been changed, and I don't like read access to a property to be a real change. There are three exceptions I allow in my personal aesthetic: * debugging code: All's fair for this case. Properties are _golden_ for allowing tracking things into a lot of code without changing that code. * instrumentation: Measurements can be accumulated about behavior, but shouldn't interact with normal operation. * performance:Achieving the same results with different performance is often the whole point of systems programming style programming. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Design Patterns
Arthur wrote: I have a line segment - defined as the segment connecting 2 points. The interface allows the points to be picked and moved. The line segment has a length. I choose line.getLength() as my API Am I - in fact - violating the Uniform Access Principal. If I am, am I violating good programming practice? OK, my take is no -- you are choosing an API. My strongest reaction has to do with your wish to deny me the ability to make another choice; API design is an art, not a science, and not engineering. The whole API is what you should evaluate. I am certain we cannot produce a set of rules that guarantee a good API, not can we provide rules to avoid a bad API. If I am not violating the Uniform Access Principal how do we express on what basis I am not? This to me has to do with the set of calls in your API. It is hard to say with a coordinates and length API, it is easier with something richer like triangles, rectangles, and polygons. The length of the sides of all of those things should show up the same way; either as attributes or method calls. Variations between polygons and triangles, for example, would make me think you are letting your implementation show through too much. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance?
Arthur wrote: Trying to handle the sudden change of state of an instance of an object - a quantum instance c starts as a Circle instance. Say, in the course of the manipulation of c its radius approaches towards infinity, and upon the radius becoming than some Max, I want c to suddenly think of itself as a Line instance rather than as a Circle instance. doable? hints? Art As a sketch: class Blended(object): MaxRadius = 123456 def __init__(self, radius): self._active = Circle(radius=radius) self._other = Line() self.radius = radius # Switch to Line if necessary def __getattr__(self, name): return getattr(self._active, name) def __setattr__(self, name, value): if name[0] == '_': object.__setattr__(self, name, value) elif name[0] != 'radius': return setattr(self, value) if value self.MaxRadius: if isinstance(self._active, Line): self._active, self._other = self._other, self._active else: if isinstance(self._active, Circle): self._active, self._other = self._other, self._active self._active.radius = value You could read up on __getattr__, __getattribute__, and friends in the Language References section 3.3.2: Customizing attribute access --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur wrote: Scott David Daniels wrote: [EMAIL PROTECTED] wrote: I think teaching programming outside a context - as an abstract discipline - is unavoidably problematic in this regard. I would have more sympathy if you would subscribe to the same philosophy for geometry and mathematics. As someone who has concentrated on computer science and The Art of Computer Programming for a huge number of years, I am offended at the denigration of my field of study (or at least what I perceive to be a denigration). OK, here I may have been unclear. TAoCP is a set of books I love, but I was, in fact, referring to the art of computer programming, and engaging in a bit of a pun. It seems to have helped confuse the issue. I also understand most of the best programmers I know are not computer scientists, though many of them read in it from time to time. And I would have more sympathy if you were willing to deal separattely and distinctly with computer science, as science and the Art of Computer Programming as an art. OK, we are getting to a nub here, but we are also moving to my personal biases rather than that of the field itself. I went to the Univ. of Penn., where Mathematics was definitely classified an Art; even Applied Math. I view computer programming as an Art, not engineering nor a science. The art is in the clear expression of a solution to a problem. Much of what you need to know to develop that art involves things like brushwork -- technical skills at which you must become proficient in order to work (the _craft_ part of computer programming), but the art lies not only in a perfected craft, but an ability to see a problem and find a solution that seems obvious once found. But, to confuse the issue a bit, I also find Mathematics and Computer Science equally arts. I personally have very little interest in (but great respect for) the former [Computer Science], and a good deal of personal interest in the latter [Computer Programming]. Maybe its harder for those who started by writing machine code to make the distinction than it is for those of us who only came to the party when and because high level languages were developed. It is indeed stimulating and challenging to attempt to communicate with a complex machine, and do so with elegance. Ah -- is that what computer science is to you, or is it programming? In my view the communication is with the reader of the program (who may be reading for the joy, but more likely is reading in order to alter). But I don't find it difficult at all to maintain that the pursuit is different in nature from the study of mathematics and geometry. Some would argue that mathematics and geometry are there whether we as a race are or are not. Certainly though they are there whether my machine powers up or does not. I am not convinced programming as a stand-alone subject cannot be optimum as an approach. Could you restate this? I presume (but am unsure) this means: I believe teaching programming without computer science is optimal. I believe computer science is a stand alone subject, and that programming is natural in the context of a computer science curriculum. But I do that think someone like yourself is in fact actually studying programming in a particular context. Maybe its most general context. But a quite specific context nonetheless. Hmmm. I think you know me less than you think you do. I think a core computer science question is how efficiently some values can _ever_ be calculated, based on as few assumptions as we can get away with making about the nature of the machines (and languages) doing the computation. These kinds of results should inform how you (or even whether you attempt to) build programs to solve these problems. Perhaps an attempt to liberate programming from the control of computer scientists is bound to annoy a computer scientist, a bit. ;) I suppose you might call me a computer scientist, but if so I am an amateur computer scientist; my CS is from the love of the ideas, not from a compensated position. My pay has come, almost exclusively, from being a programmer. I would say that writing computer programs without an understanding of computer science is certainly possible (and I've worked with lots of people who do so), but to write well, and to write are not the same skill at all. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur wrote: Back to where I started to get testy: properties and decorators I honestly believe that if I had seen them in my first Python Triangle class I would have judged myself to be looking at a language that might be swell - for somebody else. But a little too magical, self-referential and self-involved - for my own taste. And would have moved on. I understand that properties and decorators look like obscure magic. I ask you to suspend judgment on those (an act of faith), until you understand why such features seriously assist the readability of code and designs. This act of faith can be based on a respect for the obvious effort somebody has gone to in other ways to make Python such a clear and simple language. I don't object to your not wanting to use such constructs, but rather to your desire to remove them from the language (or veto adding them) in order to make it simpler. I'm sure others have said as much about the ridiculous idea of making a value for the square root of minus one, or for the incomprehensibly strained line at infinity. When you ask what these features provide, I try to explain how they make it possible to write some very clear simple code. I think Kirby will attest to the fact that decorators seriously improved the readability of his hypertoons code. Decorators should be used sparingly, if at all. That is not to say they shouldn't exist. The key to understanding when decorators are useful can be summarized as whenever you feel you are writing boilerplate your skin should itch. This doesn't mean that you should not write boilerplate on occasion, but rather that you should be searching for a way around it. I tried to explain to you why I found properties such a useful addition. Their existence allows me to write code without the protective generality of always writing accessors and mutators in case, some two years hence, I need to change more than the single attribute on a mutation, or decide some value that I have been storing is much better left calculated. This was unconvincing to you, but you responded more in the vein of nobody should be allowed to use this, so the code I read is simpler. I am surprised you accept exceptions (a relatively recent development in the design of computer languages). The rule I use in commenting code is that you should not comment use of features of a language in code written in that language. Programmers who read code written in Python are responsible for learning Python, and there is no excuse for code like: a = range(12) # Make a list of integers between 0 and 11 inclusive The comment slows down your reading of the code and distracts you from reading the application itself. The language is the given. When you choose a language, you buy its tradeoffs. If you cannot stand descriptors, insist on python 2.3. When you ask what something is good for, and get given an explanation that turns out to not make your life simpler, don't presume that the examples given are therefore useless. You have not spent a career writing code that must be rewritten constantly (to accommodate changing requirements); properties help in that task, in part because you can avoid using them until necessary, with their existence in your back pocket. Can we accept the less sophisticated approaches on equal footing? We can accept the less sophisticated approach to designing programs as workable. Do you seriously think that when designing a language equal weight should be given to those that understand the implications of a decision and those who go with their gut? It is one thing to make ivory tower decisions, and another to know the impact a decision might have. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] quantum instance
Arthur wrote: ... But I still don't see the connection to XP programming, API design Do you truly not understand my position, or merely disagree with it? --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Brute force solutions
[EMAIL PROTECTED] wrote: The fun part here is we can use numerator/denominator syntax with open-ended precision integers, to like express sqrt of 19 as some humongous fraction (as many digits as memory will allow). This lets us far surpass the floating point barrier. OK, here we go: def test_sqrt(numerator, denominator, trial): '''True iff trial (a num,den pair) over-estimates the sqrt(n/d)''' root_n, root_d = trial # return numerator / denominator = root_n ** 2 / root_d ** 2 return root_d ** 2 * numerator = root_n ** 2 * denominator # since we don't have 2.5 yet, here's a version of partial: def partial(function, *args): '''Simple no-kwargs version of partial''' def andthen(*final_args): return function(*(args + final_args)) return andthen def farey_trials(tester): '''Binary search for fraction. value must be between 0 and +Inf tester((num, den)) returns True if fract is high, False if Low ''' low_n, low_d = low = 0, 1# 0/1 = 0 .. high_n, high_d = high = 1, 0 # 1/0 = Infinity while True: mediant_n = low_n + high_n mediant_d = low_d + high_d mediant = mediant_n, mediant_d yield mediant if tester(mediant): low_n, low_d = low = mediant else: high_n, high_d = high = mediant # Now here is a cute reporter that relies on another trick: # n -n == n only if n is either 0 or a power of 2. for n, fraction in enumerate(farey_trials(partial(test_sqrt, 19, 1))): if n -n == n: # report increasingly rarely print n, fraction if n 4096: break -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Basic dictionary question
Kirby Urner wrote: Talk about fishing for expert help! Thanks Guido. It's a pruning algorithm where I strip way pieces that don't meet up at (x,y,z) bridge points. Lots of symmetry about the origin so just pure distance won't work (not unique enough). I think might still get away with a tuple-indexed dict (tallying for pairs, pruning the rest) if I boil my floating points down to fixed decimals -- a chance to play with the new decimal type perhaps. Beware: 1.999 and 2.0001 likely won't lie in the same bin. You'll need to check neighbors for candidates, unless your fixed point stuff reflects an underlying granularity. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Basic dictionary question
Kirby Urner wrote:
I'm translating a volume 3 cube around in a 3D checkerboard, trying to flag
all kitty-corner mid-edges (my bridge points), but not flagging border-line
edges where the connector tabs shouldn't appear -- some large borg-like
array of icosahedra connected by zig-zag tensed bands (Lanahan's patent
pending).
See http://www.4dsolutions.net/satacad/pythonicmath/icosa_in_holder.jpg for
a picture of a unit cell (the array might contain thousands).
So the XYZ tuples of interest are indeed highly distinct and in a regular
grid pattern. It's just that there're a whole lot of them, and if I could
find a hash key that'd keep only the unique ones unique and ignore floating
point fuzz, I'd be set. Any pairing/doubling would define a bridge point,
and therefore a green light to render a tab connector.
I think the key is probably to transform the grid by scaling, such that my
mid-edge points of interest get expressed using all integer coordinates.
Even though my actual map is floating point, the isomorphism will work for
pruning, and the tuples'll be easy to manage (so maybe scratch the decimal
type idea for now).
I'll post again when I have more research behind me and either a solution or
concrete frustration in sight -- not before.
Kirby
Does something like this work? The idea is two exact matches on the
discretization and one off-by-one on the third discretization merits
a check. discrete(point) gives the integer-ized coordinates. There
is some fancy dancing to avoid the distance check (done as the square
just to avoid a few square roots) unless possibly helpful. It only
tries to solve near-misses (skips exact matches) on the theory you
can already get the exact matches from a dictionary.
def clustered(source_of_points, threshold2)
xy = {}
xz = {}
yz = {}
for point in source_of_points:
ix, iy, iz = discrete(point)
xy.setdefault([]).append((iz, point))
xz.setdefault([]).append((iy, point))
yz.setdefault([]).append((ix, point))
for collection in (xy, xz, yz):
for parts in collection.itervalues():
if len(parts) 1:
parts.sort()
for (da, a), (db, b) in zip(parts, parts[1:]):
if 0 = db - da = 1:
if 0 dist2(a, b) threshold2:
yield a, b
--
-- Scott David Daniels
[EMAIL PROTECTED]
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] python versus __python__
Kirby Urner wrote: Kirby PS: since you've been studying subclassing primitive types using __new__, maybe you could show us a user-defined floating point type that reports two numbers equal if their absolute value difference is less than e. Anyone? Fuzzy redone a breath: class Fuzzy(float): tol = 1e-8 def __new__(cls, arg=0.0): return float.__new__(cls, arg) def __eq__(self, other): return abs(self - other) self.tol ... Here's the problem: Your notion of equality is not transitive. That's tough -- it invalidates the assumptions of the float type (and all basic types). Also, you didn't tweak hash, so a dictionary with these things in them would not find entries that turn out to be equal. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] python versus __python__
Arthur wrote: Scott David Daniels wrote: ... Getting one's arms around all the practical implications of these issues related to mutable, immutable - understanding when one should want to retain object identity, and when one should want to break it, the full implications of these decisions, howto implement one's intentions - is, on one hand - I find, fundamental to getting things to actually happen in Python as one intends, and on the other hand , challenging. It is the fundamental reason I chafe a bit when Python is described as easy. Ah, but you are concentrating on fundamental issues of language design which are, in fact, subtle. Normally the user of a language simply accepts the determination of the designer about what is mutable and what is not, and goes on from there. I think these issues are indeed fascinating, but they are issues of language design, not even issues for the __python__ class. Python allows you to play with these issues in your own classes, few other languages allow you that freedom. Because I have had trouble with these issues from day one, it ain't day one anymore, I still have some troubles with them and I prefer to think that it is challenging over thinking that I am dumb. Well, you are right. I am going down the road of the mutable complex number with my eyes (half) open precisely because I want the ability to change the value of a complex number object (and it's subclasses), without changing the identity of the object. In the first Fortran (and for a number of versions later), you called subroutines with all arguments by reference. There were people who would abuse this ability to change constants (which were shared across a single compilation unit) to find compact ways to alter things that were not properly variables. This brings new meaning to 1+1=4 for sufficiently large values of 1. If you define a class named PyGeoTriangle, you create new instances with PyGeoTriangle(some args). The connection of what you are saying here to the issue on which I am particularly confused is - well - confusing, to me. I'm trying to point out that you understand perfectly that some things are both objects and callable; you just don't realize that you do. The most obvious example is a class, while the second (and far less) obvious is an instance of a class with a __call__ method. In the case of a class that you have defined, you can use the class name itself in calls to things like isinstance, In Arthur's head there is the numeric type float, and there is the function float() - both built in. And in Arthur's head, while functions are first class objects in Python they are objects of a different nature than type in the sense of numeric type. So in some sense what I am not grasping is how class/type unification can be inclusive of verb - i.e, float(1) - and noun - i.e., type(1.) - unification - which in Arthur's head, is something else again. The magic trick of class / type unification is: we both need to name types (they must have existence as objects) for use in some functions, and we need to provide constructors for instances of that type. This is the same situation we are in about classes. The class situation is resolved by making special methods that get invoked when the class is used to call --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] python versus __python__
Beni Cherniavsky wrote:
On Mon, 2005-10-24 at 20:24 -0700, Scott David Daniels wrote:
Of course, the proper way to compare object identity is not the
__low_level__ `id()` function but the ``is`` operator:
(math.pi + 1.0) is (29. / 7.)
False
int('99') is int('99') # small integer
True
int('100') is int('100') # big integer
False
[``is`` works properly because both expressions are evaluted before the
``is`` operator is evaluted and only then the 2 values are
garbage-collected. With `id()`, the 2 values could be reclaimed
immediately because only the address is needed for the ``==``
comparison. The fact that `id(foo)` does not reference `foo` is the #1
source of confusion regarding `id()`.]
That won't save you from surprises when walking in subtle territory.
For example: # Distributive law
-(-3 - 7) is (- -3) - -7
True
But:
-(3 + 7) is -3 - -7
False
The difference is the aforementioned caching trick -- small positive
(and a few negative) integers are cached, the exact range is, I think
-5 : 100, but it is subject to change and should _not_ be remembered
(Python is free to change the number at any time; caching is an
optimization, not meant to affect the meaning of the language).
In general the is operator is asking about internals you should seldom
be poking around inside (playing with magic) except for the incantation
is None and is not None since there is one and only one None. There
are, of course, times when you are concerned about exactly this object
and those times are when is is proper, (and id(obj) might well be a
perfectly fine value supplying a total order on such objects).
The main reason I am belaboring the point is the recent mutable /
immutable discussion: you should never concern yourself with the
identity of an immutable; they are values to be compared using
equality or ordering comparisons. Two immutables built the same way
should be indistinguishable from two references to the same immutable
in properly written code. You need immutables for dictionary keys,
because (in the implementation) structure is built based on values
of the keys. If the values changed by mutating, your structure
would no longer reflect the values it contains (so some data would
become unreachable).
storage = {3+4j : 1, 4+3j : 2}
Suppose you negated the imaginary part of the object which is the
key to the value 1.
What should storage[3+4j] (where 3+4j is freshly calculated) return?
What should storage[3-4j] (where 3-4j is freshly calculated) return?
Such problems are not so much implementation issues (although they do
reveal the implementation) as problems with the definition of the
language. That's why this is subtle territory.
--Scott David Daniels
[EMAIL PROTECTED]
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python as Application
Arthur wrote: One of the things I *did* do is develop my own kind of test suite - having come to understand the importance of doing so, for a futzer. On the other hand there isn't that there are significant tests being passed now that wouldn't have been passed in an earlier iteration. The tests are there mostly as an assurance that my refactoring does not have me going backward. But offer no particular clue about how to go forward. So, my kneejerk reaction to test based development is some fear that it would lead to a development style that makes passing tests good enough. On the other hand, I don't fully understand the workflow that test based development recommends and where it leads. You'd have a lot of fun talking with Ward for a day. I am not completely sold on test-driven development myself, but I lean there which is why I call my current style test-forward. By that I mean I put the tests as early in the process as I can stand. Two things that _are_ important in Ward's ideas and mine are: start with tests that fail and make them work. It is _shockingly_ easy to make a test that accidentally succeeds even in the face of bad code. More than once I've written a bad test, and eventually figured out that the test itself is bad. When I do commercial work I have a pretty good idea where good enough is - would the client (who doesn't really understand my process) want to pay for further refinement (if they did understand my process). When I come to a no - I stop. It's never that there aren't further refinements that could be accomplished. In the for-money world, there are two other things Ward advocates. You break the work into tiny _costed_ chunks, some of which produce customer-visible results (and, perhaps) some of which do not). The ones you cannot make customer-visible get tied as pre-requisites to customer-visible chunks. You then let the customer choose what to work on next. The tests help confirm you are moving forward, not around. The estimates change, but the customer is tied in enough that he sees the new estimates each round. His choices are rarely the order you would choose, but they are his choices, not yours. Generally you try to make the chunks reflect equal amounts of work that are quickly terminable (half-day or day, for example). If you don't complete a task, you either put it back in the pile or (more likely) make new subtasks that finish this work. You track both your over-all progress, and the speed at which you dispatch tasks. You start calling your progress four cards per week, for example. Your customer comes to see you hitting your estimates, and trusts the process more. You get better at estimating and teasing out prerequisites. You can even include tasks that are break the goal into tasks if the estimate is too shaky for your tastes. A couple of things I like about this model: it keeps you honest in promising what will happen, and it keeps your customer honest in that he is not asking for free work -- only costed trade-offs are available to choose from. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Low Enrollments - programming as anti-intellectualism
Arthur wrote: As, for example, noted by Rob Malouf's recent post: We're not training our students to be programmers, we're just trying to give them the basic computational skills necessary to study language, genes, etc. There is - as I think John pretty much put - learning to program - to program, and learning to program - to learn. My own experience is more toward the learning to program to learn - in my case - mathematical ideas. But ultimately, to get to where I want to get, I realize that basic computational skills are not sufficient - that I need to get somewhat beyond the basics. I think that the linguist, or geneticist might also find the same to be true - eventually. Where are those needs to be services under current academic structures? This is why I'd call programming a writing skill. Not only should our geneticist be able to read and write programs, he should be able to know when he needs the services of a professional programmer. If you want to really understand the core, I'd suggest starting with MMIX, Knuth's new assembly/machine language. The book is slow going; a page a day is a good pace. It _does_ have answers to exercises, and some material is only presented in the exercises. If you get through the Fascicle (93 pages of presentation, 126 through the answers), you will actually have a good handle on the architecture of modern machines (one that should last you for a good 20 years) from the point of view of a programmer. It is not enough to help you design chips or wire up a machine. I wouldn't bother learning the MIX machine -- a great machine to know in the 70s and 80s because its architecture was typical of machines in those days. Once you've digested that, the rest of his works use that machine as the measure of what makes code fast or slow. You then have a great base to learn how sorting or 'll have an appreciation If you'd rather an easier start, I like Concrete Mathematics -- by Graham, Knuth, and Patashnik. Reads much faster and covers the mathematics needed to analyze algorithms. This path is a much more abstract approach to the problem. I remember in the introduction to the class (upon which this book was based), he claimed we call it Concrete Mathematics because it is hard. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Knuth's books.
First, I think they are some of the best out there. Hard to get through, but worth keeping as references for the next 30 years. I suggested them to you (rather than generally to students) because you said you felt: My own experience is more toward the learning to program to learn - in my case - mathematical ideas. But ultimately, to get to where I want to get, I realize that basic computational skills are not sufficient - that I need to get somewhat beyond the basics. Knuth was a mathematician by training, and quite a good one at that. Concrete Mathematics is a math book built with an eye to the kind of math that you need the deeper you get into CS. The others, the slowly evolving The Art of Computer Programming (TAoCP) address CS directly. The reason I was suggesting Fascicle 1 (the MMIX machine) was that I think it is an excellent introduction to current machine architectures from the point of view of a programmer, rather than that of an electronics designer. They are all tough books, but none gratuitously so. Concrete Mathematics targets (smart) undergraduates, and so might be a more accessible start. It certainly reads faster than the Fascicles, which go at the same rate as the rest of TAoCP. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] question about livewires package. . .
Andy Judkis wrote: ... Livewires graphics routines behave differently under Python 2.4.1 than they do under 2.2.3. Under 2.4.1, in IDLE, if I interactively run from livewires import * begin_graphics() circle(100,100,50, filled=True) circle(300,300,70) end_graphics() then nothing shows up until I run end_graphics(). The circles then shows up for moment, just before the graphics window is destroyed. If I run the same sequence under 2.2.3, the each circle shows up immediately when the command is executed. This latter behavior is what I want -- is there a way to make it work that way under 2.4? OK, here's what is going on. In 2.3, an Idle rewrite happened to run programs in a separate process, rather than keeping them in the same process. That meant, no matter how insane your program got, you could simply restart the shell and discard the insane process. This unfortunately also meant the event loops weren't so connected, and things like turtle graphics were nowhere near as fun (the event processing for the graphics in interpreted environment needs to be fed chances to draw). Because of this loss of functionality, you can start Idle with the separate process feature disabled by changing the idle startup from something like: python ...idle.pyw to something like python ...idle.pyw -n -- start idle with no subprocesses. on Windows: copy the idle shortcut (right-click, menu item copy; right-click on desktop, menu item paste). Right-click on your new shortcut (now often called something like Copy of Idle) and choose properties. In the General tab, you can fix the name to be something more to your liking. On the shortcut tab, change the Target entry by append a space and a -n to the target. Click OK, and you have a new Idle button which does the one-process Idle thing. I'm afraid I don't know the details for other systems, but the trick is the same -- instead of simply running idle.pyw (or idle.py), add a single -n argument to the process. As is described elsewhere, this way of running Idle makes some things nicer, but makes your idle program more fragile (no more so than the 2.2 idle, however). If you launch the new IDLE, you'll get: IDLE 1.1.2 No Subprocess You can find more on this issue addressed in (for example): http://mail.python.org/pipermail/edu-sig/2004-April/003669.html Hope this helps and is clear enough. Happy instructing. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] I've just started reading this paper
I've just started reading this paper (wish it covered Python): Lowering the barriers to programming: A taxonomy of programming environments and languages for novice programmers ACM Computing Surveys (CSUR) Volume 37 , Issue 2 (June 2005) Caitlin Kelleher, Randy Pausch http://portal.acm.org/tipsvc.cfm?id=1089734sess=%27%2BL%2F%2DP%5CK%2B30O%24%0A If anyone else wants to grab a copy and chat about it after reading, let me know. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python Programming: Procedural Online Test
damon bryant wrote: As you got more items correct you got harder questions. In contrast, if you initially got questions incorrect, you would have received easier questions In the 70s there was research on such systems (keeping people at 80% correct is great rule-of-thumb goal). See Stuff done at Stanford's Institute for Mathematical Studies in the Social Sciences. At IMSSS we did lots of this kind of stuff. We generally broke the skills into strands (separate concepts), and kept track of the student's performance in each strand separately (try it; it helps). BIP (Basic Instructional Program) was an ONR (Office of Naval Research) sponsored system, that tried to teach programming in Basic. The BIP model (and often the standard IMSSS model) was to score every task in each strand, and find the best for the student based on his current position. For arithmetic, we actually generated problems based on the different desired strand properties; nobody was clever enough to generate software problems; we simply consulted our DB. We taught how to do proofs in Logic and Set Theory using some of these techniques. Names to look for on papers in the 70s-80s include Patrick Suppes (head of one side of IMSSS), Richard Atkinson (head of the other side), Barbara Searle, Avron Barr, and Marian Beard. These are not the only people who worked there, but a number I recall that should help you to find the research publications (try Google Scholar). A follow-on for some of this work is: http://www-epgy.stanford.edu/ I worked there back in the day and was quite proud to be a part of some of that work. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python Programming: Procedural Online Test
I wrote: ... keeping people at 80% correct is great rule-of-thumb goal ... To elaborate on the statement above a bit, we did drill-and practice teaching (and had students loving it). The value of the 80% is for maximal learning. Something like 50% is the best for measurement theory (but discourages the student drastically). In graduate school I had one instructor who tried to target his tests to get 50% as the average mark. It was incredibly discouraging for most of the students (I eventually came to be OK with it, but it took half the course). The hardest part to create is the courseware (including questions), the second-hardest effort is scoring the questions (rating the difficulty in all applicable strands). The software to deliver the questions was, in many senses, a less labor-intensive task (especially when amortized over a number of courses). I think we came up with at least a ten-to-one ratio (may have been higher, but definitely not lower) in effort compared to the new prep for a course by an instructor. I am (and was) a programming, rather than an education, guy. I do not know the education theory behind our research well, but I know how a lot of the code worked (and know where some of our papers went). We kept an exponentially decaying model of the student's ability in each strand and used that to help the estimate of his score in the coming question cloud. A simplified version of the same approach would be to have strand-specific questions, randomly pick a strand, and pick the best question for that student in that strand. Or, you could bias the choices between strands to give more balanced progress (increasing the probability of work where the student is weakest). --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Python Programming: Procedural Online Test
damon bryant wrote: ... I have corrected the issue with the use of 'sum' (now ‘sum1’) and the I'd suggest total would be a better replacement than sum1. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Lowering the Barriers to Programming
Kelleher and Pausch's ACM Computing Surveys 37(2) paper. Well, I took my time getting through the paper, and like the rest of you here was left dissatisfied. The first problem I have with the paper is is that, while there is a large body of work that it covers, I am unable to discern a desiderata for whether any particular work will be included. I certainly see Python as one (very successful) attempt to address the Lowering the Barriers. Not seeing any criteria for inclusion or exclusion leaves me feeling that this paper is about a bunch of stuff I read. Clearly there has been a lot of effort here in analyzing the subject systems; simply thoroughly reading the system descriptions would be exhausting. The paper though, leaves me with the impression, I read a bunch of stuff, and this is kinda-sorta how I see the stuff I read can be classified. A survey like this should either start with a taxonomy and show how efforts fall into this taxonomy. Such a paper is about the taxonomy, and should concentrate on how well the taxonomy works. On the other hand, the paper could describe a way of accumulating research, and then produce a taxonomy from observation on the accumulation. Neither seems to be the case here. A kvetch: the SP/k claims PL/1 evaluates 25 + 1/3 as 5.3. How could this be true? When stating a possibly surprising fact, proofreading is indicated. Why is COBOL in there? If it is, FORTRAN and ALGOL certainly belong, and wherever those three belong is where Python belongs. I suspect that Turing is in this group, and I don't know that Turing was a stripped down for teaching language. Claiming that BASIC's LET statement is somehow simplifying the language for the student does not convince me; I think LET simplifies the interpreter, not the student's task, As to the chosen hierarchy, the top-level distinction confuses me: Systems to teach programming for its own sake vs. Systems to teach programming in pursuit of another goal To which class do systems to teach programming in order to teach Computer Science belong? Determining the primary aspect of programming that the system attempts to simplify seems equally troublesome, requiring a crystal ball -- I have no confidence in reading this paper that another person would cut the boundaries the same way. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The study of fixed points has been at the foundation of algorithms
Arthur wrote: re: The study of fixed points has been at the foundation of algorithms I guess what I am asking further is whether the statement is simply referencing the development of algorithms for solving the mathematical question of the fixed points of a function, in the context of mathematical programming where that particular mathematical problem might happen to present itself- or is there some implication that the problem of f(x) = x is one that has more general implications in algorithmics as a distinct area of study. I think the answer is yes (there are such implications), and that those implications show up in the functional programming world (where they like to think of everything as constants and pure functions). The places it shows up (if I understand correctly) have a lot to do with compilation and binding functions into environments where the functions themselves are a part of that environment. But this is simply a suspicion, I can't say that I've delved too deeply into this area. I suspect the other way into this is Category Theory, an area I am afraid I under-appreciate (though some say it is just because I don't get it). .. or am I asking a question that is itself too round-about to have an answer of the kind of am looking for? ;) The above is as much as I can give you. You may get more from abstract algebra people. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Textbooks
Peter Chase wrote: I'm teaching some prospective K-12 teachers this summer and propose to introduce them to Python SO: Any recommendations as to course textbooks? Or just go with Zelle and/or O'Reilly's latest wood rat book? - The students presumably have had programming courses already. - I would think that K-12 students would be happier if they could generate some graphics. - This is a 6-weeks course. Little leisure time. For the weirdest suggestion you'll get, at least take a look at Ruth Chabay Bruce Sherwood's book, Matter and Interactions http://www4.ncsu.edu/~rwchabay/mi They teach both physics and enough programming to do 3-d programming on the way to teaching physics. You might be able to make a short course out of the how to program part of the books. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 31, Issue 16
Toby Donaldson wrote: I used the Python turtle.py package last semester with about 500 first-year university students, and two problems stood out above all others: 1. The broken interaction between Idle and the turtle package. On windows, I have an icon linked to: C:\Python24\Lib\idlelib\idle.pyw -n Does this expedient not work for you? The -n means to use a single-process model (more fragile, but the interaction of two GUI loops is not there). --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 31, Issue 16
kirby urner wrote: Why is Logo out of date? Use it for 3 classes (?) to set the stage, get through with the turtle stuff, then turn to Python or something else. This idea that we should pick just one language and use it for everything, regardless, is to be avoided. That's not the real world. This is important. One of the most successful parts of my computer education was early on (the second year I'd programmed a computer) learning a language a week for the summer. Tough course, but after that, a new language didn't (and doesn't) scare me, as it does most mono-lingual students. I feel I got a much better idea of what, in general, programming was from learning wildly disparate languages. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] IDLE wish (was Edu-sig Digest, Vol 31, Issue 16)
Dethe Elza wrote: Back to the subject of improved turtles, I think there could be a two-pronged approach. The first prong would be to provide incremental improvements to the existing turtle.py (and possibly IDLE) within the standard distribution... Along this prong, how about a list of turtle.py's deficiencies? I suspect this list will to a lot to assuage Art's fears of over- elaboration. What I have read in the discussion is that a clear small interface is wanted to the internal module. ... the second would be to provide one or more advanced turtle environments, possibly interfacing with 3D (VPython) or actual robot turtles (PYRO) Obviously, these advance turtle environments would go through the Cheeseshop, not the standard distribution. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] wxPython and COM Query
Andre Roberge wrote: There's a new book that will be coming out soon which I definitely intend to buy: http://www.manning.com/books/rappin The cost of shipping to Canada is such that I will wait for it to be available through other channels (Chapter's or Amazon). However, from the link above, you can buy an e-book, which has about half the chapters available (it looks like the whole thing will be available within a month). Most of it is already available, with the whole book due quite soon. By the way, if you buy the e-book from them, you can later use the e-book purchase price as credit towards the purchase of the paper book directly from them (which will be at full retail price). --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] suggestions about turtle.py
Just for fun I stole some of the turtle code, added docstrings, used
complex as position format, and made a small (but not entirely minimal)
turtle class. I figured this might do as a straw-man for Myrtle the
Minimal Turtle. I do like Christian Mascher's idea of making a turtle
with a contained Pen being how to control all of the dir() results.
--Scott David Daniels
[EMAIL PROTECTED]
# $Id: myrtle.py 1.3 2006/03/04 22:54:25 daniels Exp daniels $
'''Myrtle the minimally complex turtle'''
from math import sin, cos, tan, pi, atan2
import Tkinter
__version__ = '0.3'
__all__ = 'Turtle pi'.split()
class Turtle(object):
_root = None
_canvas = None
def destroy(self):
'''Wipe out evidence of where the root and canvas are'''
root = self.canvas._root()
if root is self._root:
self.__class__._root = None
self.__class__._canvas = self.canvas = None
root.destroy()
def __init__(self, canvas=None, root=None):
'''Make a turtle, and a canvas pen for it to play in (if necessary)'''
# Make a canvas (and a root) if necessary, record root.
if canvas is None:
if root is None:
if self.__class__._root is None:
self.__class__._root = root = Tkinter.Tk()
root.wm_protocol(WM_DELETE_WINDOW, self.destroy)
root = self.__class__._root
if self.__class__._canvas is None:
canvas = Tkinter.Canvas(root, background=white)
canvas.pack(expand=1, fill=both)
self.__class__._canvas = canvas
canvas = self.__class__._canvas
elif self.__class__._root is None:
if root is None:
root = canvas._root()
self.__class__._root = root
self.canvas = canvas# The canvas playpen for our turtle
self.items = [] # things showing on canvas
self.tracing = True # moving in little increments
self.arrow = 0 # The visible manifextation of the Turtle
self.reset()# Set other things up
def reset(self):
'''Erase the canvas and place the turtle in the center'''
self.canvas.update()# Make sure canvas is up-to-date
# Find current window sizes, and set origin and position at center
self.position = self.origin = self.window_dimension() * .5
# Set step-scaling and direction to right, 8 pixels
self.heading = complex(8.)
self.drawing = True # False for Pen-Up operation
self.width = 1 # width of the line the turtle leaves behind
self.ink = black # color of ink Turtle currently wielding
self.filling = 0# polygon (1), smooth (-1), or non-fill modes
self.path = [] # Track of positions for use by fill modes
self.clear()
self.canvas._root().tkraise() # Pop turtle's canvas to top-o-screen
def window_dimension(self):
'''Get the width and height of the canvas'''
width = self.canvas.winfo_width()
if width = 1: # the window isn't managed by a geometry manager
width = self.canvas['width']
height = self.canvas.winfo_height()
if height = 1: # the window isn't managed by a geometry manager
height = self.canvas['height']
return complex(width, height)
def clear(self):
'''Drop all known elements from the canvas'''
self.fill(False)
for item in self.items:
self.canvas.delete(item)
self.items = []
self.hide()
self.show()
def fill(self, flag):
'''Fill path so far, then 0: no fill, 1: polygon fill, -1: smooth
fill'''
if self.filling:
if len(self.path) 2:
# can't create filled anything with less than 2 points
path = [(p.real, p.imag) for p in self.path]
item = self.canvas._create('polygon', path,
dict(fill=self.ink,
smooth=self.filling 0))
self.items.append(item)
self.canvas.lower(item)
self.path = []
self.filling = flag
if flag:
self.path.append(self.position)
self.forward(0)
def show(self, position=None):
'''Make the turtle visible (if tracing)'''
if self.tracing:
if position is None:
position = self.position
back = position - 2 * self.heading
self.hide()
self.arrow = self.canvas.create_line(back.real, back.imag,
position.real, position.imag,
width=self.width,
arrow=last,
capstyle=round,
fill
Re: [Edu-sig] A Quick Puzzle
Tim Peters wrote: That vaguely reminds me of a puzzle I enjoyed much as a kid: on what day will you be half as old as your father? a third as old? a quarter as old? three-quarters as old? nine-tenths as old? ... It's a good way of showing that x/(x+d), for fixed positive d, approaches 1 from the left as x goes to infinity. Unfortunately, my own father died before I became twice as old as him ;-) I called my father up within an hour of when he was twice as old as I. I was expecting a real you are such a dweeb conversation, but he wound up talking a lot about what it felt like when I was born. It was such a wonderful surprise; a great conversation for both of us. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Entering Squeakland
kirby urner wrote: I think you owe it to yourself, and perhaps to us, to understand and express why Squeak does not represent the perfect environment for pursuing the kind of educational ideas that you tend to express. If it in fact does not My own concerns start exactly there - with the word environment. My understanding is that many conclude that too much environment is what doomed Smalltalk to a minor role in today's software world. Yes, there's lots to say about this (most of it not by me). In SmallTalk what you save is the image -- which is the world as you've massaged it and messaged it up until now. You pass whole worlds around, more than fragments thereof. Context becomes everything. This is both the strength and weakness of Smalltalk: Then environment is a single, learnable model. You can look into the guts and see how it works. Yo can change the way the system works and see the effects of the change. This is gold for the tinkerers among us. What techie-kid has not wanted to take things apart and see how they work with a bit of a twist? It becomes hard to build separate things that work well with anybody's hallucination of what the core is. This is a problem with Lisp and Ruby systems as well. The other problem is the one world model which Smalltalk shares with Lisp, APL, and Prolog (and many others). My guess is SmallTalk wizards long ago added the atomism people were missing, but by that time, the other language designers had already absorbed the OO paradigm, and were reimplementing it in C (to give us C++, Java, C#) and in Python. But many shared Smalltalk things involve mucking with the core objects: This is my nifty whizz-bang: just add these methods to 'object' and then you'll find that -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
[EMAIL PROTECTED] wrote: Instead of having my geometric objects of the complex plane *be* complex numbes, there is certainly the solution of having a complex number as an attribute of these objects - and then I can take more your approach, and at the speed of C, since I would then be using the built-in for arithmettic operations. There remained something unsatisfying to me about that approach. Until something blows up about my current approach, I am quite happy with it. The thing that typically blows up is when you are (for example) computing with a complex number that is changed halfway through the computation by another thread (say a mouse drag). The square root winds up being neither the square root of the original number nor of the new changed number. Further, it becomes dicey to try to prove that your square root function will always terminate (a step size from one that is guaranteed to settle might be a disaster at the new-improved value. So, that's why CS people like immutable primitive types. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
because both a and b are aliases for the same object. That's no problem for immutables (one version is as good as another), but can cause surprisingly hard-to-find bugs. Note aliases are _much_ harder to detect than simply this case, and the results can be nasty. Some people have proposed that program have no side-effects to solve this, but others among us consider that absurd: a program models reality, and reality is mutable. There is no way to write to a printer and then abandon that calculation and move to another where the printer has not yet been written upon. So I've gone on at absurd length here to explain why immutable primitives are preferred. The reasons are subtle, and come from shared experience on building languages. This is why some of us study computer science; we are interested in such questions. It is frustrating sometimes to be asked a simple-to-ask question that seems combined with a nasty CS elitists attitude. There _is_ a body of work in CS, what it talks about is not trivial, and it builds on itself in a way that makes it hard to answer some questions succinctly. Some of the questions feel a lot like, why so many planar surfaces in architecture; to answer them requires work, not simply in the saying, but in looking back for the whys. Often the first answer it makes my skin crawl is the real answer; some rule has become so internalized you don't know why you feel it. It doesn't necessarily mean Kirby was saying you had done an incredibly stupid thing; it might simply mean that something about that as design felt dangerous to him in some way. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Arthur wrote: ... Isn't the creation of any class the creation of one's own type? Now what am I missing now? Ahh, I thought we were talking about language primitives. The range of behavior for non-primitives is larger. For example, a Vertex in 3-space for a polyhedron might have mutable x, y, and z properties just so that shared points and coincident points are distinguished. My class - unless I am missing something else - does complex mathematics exactly as does the built-in type. But it is now the Complex type, say. Which allows me to say a=Complex(5,3) on creation, and a.real = 6 somewhere down the line. Obviously notation ally, a=5 +3j will still return the Python immutable built-in type. Which is fine by me. I thought you had been asking why it was wrong to make a primitive mutable. That's exactly why I am having so much trouble with the problem I seem to be causing here. I understand next to nothing about threading, but can't understand why this particular class is any less safe than any other class one might create and use. It is not, except for one thing: one often thinks of complex numbers as values, and when they are mutable, they are more objects than values. It is dangerous in that users of the type may have wrong intuitions. ...But no, *don't* like to give up performance, and have been happy to have had a discussion that led me to a possible alternative that is prettier, *and* faster. OK, so one big performance gain is that immutable values can be safely shared, a copy is never a meaningful operation on an immutable type. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Arthur wrote: The small problem at the moment being the laptop on which I have my latest working version ain't taking well to getting powered up. ARG., Laptops are, in my experience fragile little beasties. So, this discussion has led me to think about a structure like: import numarray class PointHolder(object): def __init__(self): self.points = numarray.array((0., 0., 0.)) self.nextalloc = 0 def new(self, point): if self.nextalloc = self.points[0]: self.points.resize(((self.points.shape[0] * 2,) + self.points.shape[1:])) result = self.nextalloc self.points[result] = point self.nextalloc += 1 return result def positions(self, index): return self.points[index] class Vertex(object): positions = PointHolder() def __init__(self, point): self.location = self.positions.new(point) def position(self): seturn self.positions.position(self.location) A Vertex is a point on a polyhedron and it is shared by all of the faces that contain it. The 3-space position of the point is kept remotely in a numarray (or Numeric if you prefer) array named Vertex.positions.points; the position of a particular Vertex is available as a method. The value of such a system is that you can apply a transformation (scale, shift, rotate, ...) to all points in a single matrix operation. The work to do such transformations would be proportional to the number of distinct vertices, rather than to the number of mentions in such structures as faces making up a polygon. What got me thinking about this was why would you want to share mutable state on complexes (and then on points) -- the answer is when you are applying a uniform transformation to a bunch of points. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Christian Mascher wrote: Scott David Daniels wrote: copying to a minimum. With immutables, you needn't do any of the bookkeeping. It is not that you have gone terribly wrong; it is that you have opened the lid on a large class of avoidable problems. If you look at Java's strings (as I remember -- it has been forever since I studied Java at all), you will find they are mutable. You also find that Java code copies strings a _lot_, just to be safe against lower- level mutation. Incidentally, Java's strings are immutable, too. Quote from Head First Java (p. 589): For security purposes, and for the sake of conserving memory ... Strings in Java are immutable. Sorry about the mis-information, it has been too many years since I looked at Java. Perhaps I was remembering Pascal or Ada. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] The end is near :)
[EMAIL PROTECTED] wrote: From: kirby urner [EMAIL PROTECTED] Alice is not big on my radar. Glad to hear it. It's not even a Python project. It is brought up here and now specifically in the context of it having been noted at U of Mich as competition to and with a Python project, in fact one funded by the PSF. Are comments by me, here going to influence outcomes. Probably not. Worth a shot? What's to lose. The attention and discussion that used to go on on this list about Python and education. When you post at a ration approaching, and at times exceeding, half of the discussion a number of people slowly (or not so slowly) go away. That is what's to lose: conversation with others. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] list newbie
Kris Olson wrote: I am new to teaching Python but have enjoyed the reaction of my students to Python. I have been using the interactive mode to demonstrate it is hard for them to see when I get down to the bottom of the page. Is there a way to clear the screen or open a new interactive screen? Here's a trick I use for myself when the shell screen gets too full: 1) Make sure another window is open (do File / New Window if needed). 2) Close the shell screen. 3) On (one of) the open window(s) do Windows / Python Shell. You now have a nice clean window. I agree it would be nice to be able to prune the shell window contents. Especially if you have output some long text w/o returns in it, scrolling can get painfully slow as the output accumulates. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Accessibility to non CS types?
Andre Roberge wrote: ... Let me give a concrete example explaining inheritance for non-computer scientists. === class Father(object): ... class Mother(object): ... class Child(Mother, Father): ... === The computer scientists in the (virtual) room are probably horrified. Yup. I am aghast. You are using the built-from relationship. For yourself this is fine, but pedagogically it leads to very bad habits. The reason I am appalled is that I have maintained code that was written this way, and the mess that results over years of extending from such a shaky foundation is scary. I would claim the above example would be appropriate for the average person. I claim this is because you are a scientist, not a mathematician. At Penn, Mathematics was an Art, not a Science (I have great sympathy for that classification). You are in the habit of lying to your students and, next course, telling them you know, what you learned in the previous course was wrong. This is a reason for people leaving the sciences. Mathematicians tend to try to stick to truths, though they expand the universe they talk about each time. In part this distinction in approaches makes sense because mathematicians who make mistakes are corrected (and scorned) by other mathematicians, while physicists are corrected by reality (and refine their models). Computer Science is a funny field, reached from both mathematics and engineering, so the ideas you see there can come from either of these sides (and cause lovely fights in faculty meetings). I consider CompSci an architecture-like discipline, with mathematics holding the position in CompSci that physics has in architecture. Words like inheritance have been borrowed and adapted by computer scientists for use in their own discipline. While words like spin for physicists Natural languages seldom have precise definitions, and Computer Science is not close to the worst offender in this respect. To follow up on Kirby's personal history suggestion: I was a math loving kid by fourth grade, came to computers by accident in summer after 9th grade (in 1966) doing machine language on a vacuum tube computer (LGP-30). The following summer I spent full-time in an NSF-sponsored class at Penn where we a language a week for the summer (two programs per language). The experience gave me a good feel for what a programming language is in general, as well as specifically. I decided around 1972 (after auditing a class or two from Knuth) that I could be either a mediocre mathematician or a very good computer programmer. Twenty years ago I went back to school to attempt a PhD as a teaching union card in CompSci, and got a drop-out masters. For my research I was trying to do Query Optimization in Object-Oriented Databases, and glanced briefly at Python (the type system did not fit my research needs). After working in compilers and Databases after school, I picked up Python as a way of pursuing a long-running personal project, and had the most fun I've had in a new language in 30 years. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Talking about Handles
kirby urner wrote: We say reference a lot when talking about a variable's relationship to a piece of memory. I'm thinking handle could be used more (optionally -- this is not an instruction) and we could even show a coffee cup (doesn't have to be coffee -- a mug) with two handles, when explaing how two (or more) variables may have the same contents (a feature, but also a source of bugs, confusions for beginners). This metaphor may be good for references, but not for Python. You are left with the intuition that you can look at the mug and enumerate the handles. Maybe a an object is a living thing with lasers shining on it (referring to it), that may shrivel up and die if it gets no light. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Talking about Handles
I'm catching up here, and just read the namespaces thing -- How about namespaces are like card catalogs in a closed stack library. At the Library of Congress (here in the U.S.), up through when I last went (some time ago), any U.S. citizen can go in and find a book in a catalog (I'm certain electronically automated by now) -- they are kind of sprinkled around as I remember), fill out a slip of paper, including a desk number, and wait at that desk. If no member of congress has the book out, it shows up on that desk, often in less than 20 minutes. If a book wound up in the library with no entries in any catalog, it would effectively be gone, whether or not the buildings vast archives held the book. The books don't care, however, how many different cards reference them (nor even if the only reference to them is written in some book which _is_ referenced by some card in the catalog). -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
kirby urner wrote: Scott mentioned our not being able to see how many handles a mug has, but with the sys module we can: Perhaps I said that, but what I _meant_ was that you could see the handles. In my mind, at least, there is a huge difference between seeing the handles (what is this value's name?) and knowing how many there are. I just don't know a nifty concrete-world analog to that. The Library of Congress idea (too flawed, I agree) was neat because objects (books) could become lost without a librarian noticing. Then on to: Well, if there were a count, and, .. -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Truth values and comparisons
Arthur wrote: some code with an issue addressed by Dan Crosta ... Is concerning myself with this distinction sound programming, or is the hard core answer more to the effect what works works, what doesn't doesn't - and one should focus only on that, and perhaps the performance impact of available alternatives? For my money (and that of most professional programmers I don't revile), it is _vital_ to concern yourself with such distinctions. Writing code should be an exercise in how do I express this the most clearly, not how can I make it run as fast as possible. Code first must be correct, then obviously correct, then fast enough (which in some special cases is as fast as possible). Clearly correct can either come from how the code itself is written, or (if necessary hen getting the speed up) through comments that help the reader understand why it is correct. Though I guess we are all allowed to define sound programming for ourselves. With the exception you pointed out about space shuttles. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Learning (some more) programming
Arthur wrote: Have dug in quite a bit to VPython's code, which has become an intensive C++ course for me. And have accomplished a good deal in keeping the project moving forward, healthy and on-track. I happen to be proud of that. I recommend you read Stroustrup's book, The Design and Evolution of C++. It will give you a nice skeleton around which to wrap your understanding of C++, and help you understand how C++ came to be the way it is. --Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] CS0 course
Andre Roberge wrote: Does anyone have experience with teaching a CS0 course structured like this? Are you aware of any resources that I could use, mostly in terms of assignments idea? (note: they have to be either in French, or things that are short enough that I could translate them without having to invest too much time) Thanks for your time reading this message, and I welcome any suggestion you may have. Check in newsgroup fr.comp.lang.python. It is fairly active (nowhere near comp.lang.python), but I'm certain there are resources. -- -- Scott David Daniels [EMAIL PROTECTED] ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Mystery Number 6174
kirby urner wrote:
Yutaka Nishiyama has this interesting article in the March 2006 issue
of Plus, entitled 'Mysterious number 6174'.
The theorem in this article is as follows: any 4-digit positive
integer, stipulating all 4 digits *not* be the same one, may be
distilled to 6174 by the following
process: extract the largest and smallest two integers from the 4
digits and subtract the smaller from the larger, and repeat as
necessary.
...
Here's one way to test the result. Think of a different way?
def counts(limit=7, closer=6174):
counts = [0] * limit
exceptions = set()
for ournum in range(1):
start = quad = ''.join(sorted('%04d' % ournum))
if quad[0] == quad[3] or quad in exceptions:
continue
for distance in range(limit):
diff = int(''.join(reversed(quad))) - int(quad)
if diff == closer:
break
quad = ''.join(sorted('%04d' % diff))
else:
exceptions.add(start)
counts[distance] += 1
return counts, sorted(exceptions)
-Scott
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] What is the Best Way to use Python in the Windows Command Line
csev wrote: ...We share intro documentation on how to install and set up ... I end up publishing detailed documents and screen casts to get python into your Windows path. It works but it is not where I want students energy focused in the first week of class. I am wondering if there is another way. Have you considered contacting ActiveState? Their installers generally work very nicely for me, and I like to recommend them to people who want a turn-key install. I suspect you could talk them into some special deal to redistribute the installer as an academic institution, but at the very least your students could download their installer themselves for the economical price of $0.00. --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] Python 2.6.1 build problems
Arana Fireheart wrote: ... The second and currently un-resolvable issue is that the build fails to link in tkinter. I can't quite figure this one out, since I thought that this was part of Python. Is there anyone out there that has figured out how to get this build to finish? I've kinda run out of tricks! It is essential to have a Tcl/Tk development package installed before configuring Python. I don't know enough about what packages you need for Ubuntu, but check into it; that may be the problem (than make clean ./configure, ) --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] Many Laptops per Adult
gerry_lowry (alliston ontario canada) wrote: If the idea is shared laptops, probably a single laptop configuration would suffice for the following reasons: That's a very nice idea, as long as you figure out how to make me right-handed, convert my eyes to 20-20, and fix my former colleague's color-blindness. Some customization is (or should be) portable, and it is, in fact, necessary. When I was younger, I used the smallest font that I could read, in order to get the most letters on the screen. In essence I do that now, by choosing a high-resolution display and picking a font carefully for legibility. The letters are larger now in absolute terms, and _much_ larger in pixels, so I suffer with web pages and applications that think they know what size text takes. One size fits all is short for one size fits all that fit. --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] Pythonic Math must include...
michel paul wrote: ... An interesting fact is that, except for 2 and 3, all primes are adjacent to a multiple of 6 Having once been interested in prime pairs, I remember having written a lot of code based on this back in the day. Here is my version of your generator: def primes(): for x in -1, 2, 3: yield x gen = primes().next for top in iter(gen, 3): pass # skip useless tests (we skip all multiples of 2 or 3) factors = [] # get pump ready for a 5 check = -1 limit = 3 * 3 - 2 # How far will 3 work as top prime? factors = [] while True: check += 6 if check = limit: # move if this pair needs another factor top = gen() limit = top * top - 2 # limit for both candidates factors.append(top) for element in check, check + 2: for factor in factors: if element % factor == 0: break else: yield element --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
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
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] As We May Think: What will we automate?
kirby urner wrote: One of our Wanderers (think tank in Portland) wrote: I expect that teaching Python/Perl/Ruby/Java in the 2000s will be viewed with the same scorn in the 2030's. The problem with flavor of the month languages is that they are passe a month later, as better abstractions appear. Such evanescent ways of doing things are probably not the basis for life-long learning. ... So take a look at programming in schools from the viewpoint of an adult in 2030, not a 2009 viewpoint, and heaven forbid from the viewpoint of the ancient times when you and I were trained. What do you wish you had been taught 40 years ago? What was fashionable but dated? Extrapolate that forwards, and try to guess what they will want, not what you and I consider important /now/. For extra points, try to guess what they should be teaching *their* kids, for use in the year 2060, and get started on the theoretical underpinnings of *that*. To which I'd reply, this is like some reviewer in Chaucer's day saying, Chaucer's writing in Middle English, is such a passing fancy, let's imagine how people will want to use text messages on their cell phones. After all, Prediction is hard, especially about the future. I'll tell you this, in my technical education, I can think of very little that I learned in any of Knuth's classes that is obsolete, and that included working with the MIX computer's machine instruction set. I like the newer machine (a RISC family of instructions) code, as it presents issues from modern architectures more clearly, but getting down all the way to machine code makes you smarter about what is inevitably slow. At the other end, Python gives me a language I can talk to another programmer in, and I can also run parts of the discussion on a machine. There are other languages that do that, of course, but none that are so easily communicated to a random other without spending more time talking about the mechanics than about the idea. I suspect this is why Kirby likes APL so much, he can easily express large-swath ideas. For me, APL too quickly becomes terse little chunks. But Kirby and I program about different things. --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] As We May Think: What will we automate?
kirby urner wrote: At the other end, Python gives me a language I can talk to another programmer in, and I can also run parts of the discussion on a machine. There are other languages that do that, of course, but none that are so easily communicated to a random other without spending more time talking about the mechanics than about the idea. I suspect this is why Kirby likes APL so much, he can easily express large-swath ideas. For me, APL too quickly becomes terse little chunks. But Kirby and I program about different things. --Scott David Daniels scott.dani...@acm.org Yeah, plus when I got involved with APL in 1976-1977, we didn't have Python. This was the first / only language with REPL in my reality, i.e. I could type at a terminal and get an immediate reply, what a difference! Same think people like about Python. My APL is rusty by now, so if someone wants to collaborate with me on communicating some large-swath ideas in at least partly working code, I prefer Python. Like here's some manga code from the PPUG list: http://mail.python.org/pipermail/portland/2009-March/000637.html Thanks for you input Scott. Kirby You should definitely take a look at http://arstechnica.com/science/news/2009/03/building-a-better-way-of-understanding-science.ars as this is where Python can be very useful in science -- the stand at a whiteboard and scrawl and argue phases. I do it for computer science, but I've used it to talk evolution with a creationist -- explaining how recognizers can (and are) trained to match things from weighted inputs and evaluate-crossover cycles where the programmer has no idea how to solve the problem, but can train a machine to do so. --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] As We May Think: What will we automate?
Bert Freudenberg wrote: On 23.03.2009, at 10:38, kirby urner wrote: I think [...] that there's a backlash against lexical coding as that means typing Not at all, in my opinion. It's not against having to type, it's about covering distance one step at a time. I like to compare the issue to this: When kids first start to understand and speak themselves, it would be quite detrimental if they were forced to use correct grammar or even speak the punctuation out loud from the beginning. They will have enough time to learn that later, after the basics of language are internalized. When you introduce the concept of programming, learning the syntax is only one of the challenges the student has to master. If you can focus on statements, sequences, passing arguments etc first without having to introduce syntax at the same time, you remove one big hurdle. What worries me about this is that you seem to be traveling down the Cornell Program Synthesizer path. That was a fully visual language that intended to change the way we all write programs. One of my most frustrating graduate school experiences was in working with LML (Lazy ML), which defined its structures in trees. The problem is that humans don't see trees (insert forest/trees joke), and so the computerand I were communicating in text. Unfortunately, I had stumbled into creating a chunk of code that was represented in text the same way that the correct program I was attempting to get in was represented in text, but was a distinct program. At that point I fell out of love with programs are data structures, and began to realize that programs are ways that humans communicate with other humans and with computers. We should be the masters, and I should be able to go off into a field to look over a knotty problem. This issue is why I am so not in love with fancy aids in generating code; I want to read what the original programmer wrote, not the pile of garble that got blasted out when he pushed some buttons and dragged some boxes. I'll need to check his logic, determine where he went wrong, or follow and extend it to enable unanticipated requirements. Programs are (or should be) communications about the solution to particular problems, not to the computer, but to future humans reading the program. --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] Progamming advice. (Was: Why MIT switched from Scheme to Python)
Gary Pajer wrote: ... Just this past weekend I was wondering where I could find such things, that is, help at learning good ways to structure a python program (for generic python, not specifically Django), written for the non-programmer scientist/educator. When I write my programs I always feel that certainly I am attacking the problem in the least-elegant, least-extendable, least-reusable, most-brute-force way possible. It's easy to find beginners manuals, but what's the best way to learn better programming techniques / structures / etc? OK, I may be CS-biased, but I think a data structures course, taught well, can be the quickest way to get to core structures you'll need. As to general programming rules: much like in writing in English, go for short clear exposition. Think of a program not so much as controlling a computer as describing to another programmer how you go about accomplishing this computing task. Just as you don't write twelve-page paragraphs; don't write 12-page functions or methods. Remember the other programmer may be you in year or two, so be kind about making details clear. Although this is tangential, I've recently been remembering one of the great moments in Corporate Politics JuJitsu that I experienced decades ago. I was working in an OS and Languages group, and we would regularly get requests for short programs do just do something simple. We would give estimates that frustrated the requester, in that we'd be taking a week for what may well have been a half-day programming task. Of course, a lot of our maintenance work consisted of coping with hack- on-hack-on-hack software. Finally, we hit upon a solution. We offered two-pronged estimates: one day if we delete the source before delivering the program, or one week if we keep the source. The dual-estimate satisfied everyone. We had the luxury of getting things right to support, without over-charging for things that were truly one-off productions. It was amazing how many one-time requests wanted the full week version when they realized that what you did last week with this little change was going to cost them a full redevelop. These days I see this as matching the Agile Programming goal of leaving the customer in charge, but then I just thought it was a miraculous way of explaining explaining what the extra time went for. --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] What version of Python to teach ....
Laura Creighton wrote: One note: It is very important to teach your students how to read code. I think that this is even more important that teaching them how to write code -- not only will they spend more time reading code than writing code in their lives, but it is through reading other people's code that you can learn any technique for writing code. (Well, that, and a whole lot of practice, but a certain amount of reading of code every day can cut down on the number of things that you have to learn by doing.) There isn't a lot of Python 3.0 code out there to read. So even if you are only teaching your students how to write 3.0, you will still have to teach them how to read 2.x. But here is a learning opportunity as well -- too many students are used to received wisdom, and assume there is nothing to discover. To say that Python is in motion, that we have learned from our mistakes, that we are forging a new way forward, and that they can be a part of how to say things well in this new language is to begin to explain that things are moving and they can be a part of that movement. One of the great disappointments from teaching my first computer science class (operating systems) came after a lecture where I discussed some of the publications going on about these new-fangled RAID systems. I had students explain to me that a new way of organizing file systems could not be as efficient as I described, because Microsoft and IBM would be using such designs if they really worked. Students need to know that not everything has been done. --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] F.Y.I.: this month's cover story for CACM is OLPC: Vision vs. Reality (cross posted)
gerry_lowry (alliston ontario canada) wrote: heading F.Y.I.: this month's cover story for CACM is OLPC: Vision vs. Reality (cross posted) http://www.acm.org/ Also note, in this issue Mark Guzdial has a Viewpoints article entitled Education Teaching Computing to Everyone. The article discusses Georgia Tech's policy of all undergraduates students must take a CS course experiences for the last ten years. They talk a lot about the success they've had, but at the cost of making several distinct courses. The requirement they used was, students would 'be able to make algorithmic and data structure choices' when writing programs. Initially they used a course that had a success rate (end wit C or better) of 78% overall, but architecture, management, and public policy majors were at below 50%. Also, females failed at twice the rate of males. After moving to the newer cross-developed courses, they had those three groups all at over 85% success. They did three basic courses, the ongoing CS course, a MATLAB-based course for engineers, and a media computation (manipulate sound and images (really, at the level of pixel manipulation, not just crop and bind) using Python. The media course used Python as the language. The new media course achieved an 85% success rate for the three groups above, and had women succeeding at the same or better rates than the male students. Apparently Guzdial wrote the thextbook for the media course, Introduction to Computing and Programming in Python, a Multimedia Approach, Prentice Hall, 2005. This change was so successful that, second courses for both engineering and media are now in place (the demand was high), and they've introduced a CS minor. --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] poking around in Py3k (recycling old algebra)
kirby urner wrote: ... Hey, did you know Ellipsis is a new primitive object in Python 3, denoted ... ? ... Ellipsis Actually, it has been around for quite a while. Try this in even a much older Python: class Funny(object): def __getitem__(self, *args): return args Funny[1, ..., 10] (1, Ellipsis, 3) Ellipsis Ellipsis --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] poking around in Py3k (recycling old algebra)
Scott David Daniels wrote: kirby urner wrote: ... Hey, did you know Ellipsis is a new primitive object ... Actually, it has been around for quite a while [broken example] Sorry, everybody, I started writing, tried the code, and editted the reply, rather than taking direct quotes. In doing so, I slipped up. I'm embarrassed enough that I'm going to re-post: class Funny(object): def __getitem__(self, *args): return args psuedo_array = Funny() psuedo_array[1, ..., 10] ((1, Ellipsis, 10),) Ellipsis Ellipsis Just to add some actual content: I believe this was first put in to help out array processing and heavy computation projects. The biggest survivors / descendants of those projects are Scipy Numpy. By the way, Funny is actually a fairly useful class for experiments. --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] mentions of Py on Math Forum....
kirby urner wrote: I haven't tried 3.1 yet, have been using dictionary versus list to harp on the cardinality vs. ordinality distinction (per Midhat Gazale), understand there's a new kind of dictionary that has ordinal properties You really should. The io module went to C, so simple file I/O is substantially faster. It had been slowed down to make sure the semantics were all correct for where the Unicode and where the bytes should be. There will be no fixes to the 3.0 line, 3.1 is the ongoing Python 3.* version (3.1 was a quick follow-on to address issues discovered in the 3.0 release (think if 3.0 as a Python 3000 alpha or beta). --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] more on digital math...
kirby urner wrote: ... Another piece of feedback came from this PSU professor who really likes the language but found IDLE to be almost a show stopper on her Mac, as it'd crash and then not reboot because of some socket error. I mentioned killing zombie snakes in the task manager on Windows but she assured me this wasn't the problem, plus her students reported the same thing. Her impression was IDLE is not supported and that there's no one to turn to when your IDLE is crashing. I said I'd look into this for her. I've not had this specific problem, though I do need to kill zombie snakes on occasion. My hope is tat with Snow Leopard we get to a more stable Tkinter, and because of that, a more stable Idle on OSX. I've no inside knowledge about whether that will come true, but I'm hoping the Aqua vesion of Tk will do the trick. I see a little movement of fixes connected to Idle (as in I finally got a note from someone about an old Idle Patch of mine), so there is definitely some reason to hope. If Tk is not stable, there is no hope for Idle. If Tk gets stable, I think we ought to be able to repair the Idle bugs. I personally think Idle is crucial to learning Python easily. If Idle does wind up broken, perhaps the better educational scroungers could rustle up a few shekels or skilled software hors to fix it. I'd make sure they know about numpy and/or scipy as well, because having easy matrix calculations is a _big_ win as you get into 3-D calculations. --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
