From goodmansond@hotmail.com Sun Jul 1 21:36:26 2001 From: goodmansond@hotmail.com (Dean Goodmanson) Date: Sun, 01 Jul 2001 20:36:26 -0000 Subject: [Edu-sig] Post request and Dead-link note Message-ID: Dear Educators and Programmers, I had indented to shorten this off-line written post but in the event of the last few days lull am going to lob it out there. Please bear with me. I have been enjoying the EDU-SIG list for a few weeks and Python for slightly more. I have been doing C/C++ (and some Java/C# exploration…does that make me a C? or Cn programmer?) development for the last 3+ years. My current educator associates consist of my sister who is a 3rd grade teacher and my wife who is certified in high school English. I find the list’s educator discussions and insight very interesting. My wife’s has little programming background but showed interest in the linguistics aspect of a language. (Last time she programmed was with BASIC on an Apple II but her teacher essentially would write the student’s program whenever they asked for any type of help.) During the peak of her interest I suggested Java as I had heard it was the language of choice for intro to programming. We didn’t get past the intro and first chapter of Bruce Eckel’s “Thinking in Java”. We never made it to the syntactical nuances and programming concepts of Java. Since, she has pretty much lost interest but still willing to let me discuss with her enjoyable Python language nuances such as “pickling” and catching my slip-ups including “Python’s style is more restrictive than Perl.” I’m speculating her interests are in the logical control & communication concepts, not the computer concepts- -er, perhaps, How do you [programmers] describe, implement and guide an automated process [To Users, Implementers & Machines] through a computer language instead of How do you make a computer remember a piece of information and it’s reference to it. (Memory management topics are my worst fear for intro language distractions.) I’ve personally enjoyed the Learning to Program book primarily because he explains fundamental programming concepts well and (lo and behold!) with a language that’s easily decipherable. It’s nice to map and re-enforce concepts in one language & framework to those in another, while discovering overlooked ones. So I’ve focused my attention on my 2 and a half year old's computer interests: He can’t control a mouse, but he can control the motion buttons on my plotter...too bad those buttons are right next to the other controls and grab-tempting moving paper and pen carousel. My initial goal is to develop a joystick control by implementing a joystick reader in python to interpret and then send out HPGL commands to the plotter. PyGame and ActiveState’s tools seem to be appropriate here. (Having trouble finding an HPGL spec, any links would be appreciated.) Last time I was excited about this kind of thing was with my Tandy Color Computer with BASIC and an analog joystick interface. I didn’t get to it for hardware, cost and computer usability reasons. Python has filled the gap for a simple language and hopefully PyGame with a simple Joystick interface. My son has most letter and single digit (decimal ;-) ) number recognition but doesn’t really understand measurement applications. He happily yells out “26!” whenever we ask him the time or a measurement. I’m curious to see how a controller scenario and/or Logo type application will help him grasp these concepts. In my experience I have come to some conclusions you may be interested in: 1. Could this kind of thing (robotics, or even 2D robotics…) motivate students to learning an all purpose language? (I certainly enjoy controlling and gathering data with a computer from external devices. In the plotter case researching and building the tool is more fun than using it.) 2. There seems to be a lot of potential applications for this kind of physical input/output scenario. Essential elements are the Data acquisition device and an output device ranging from a graphical display to printers, robots, switches and servos. Input projects could range from weather analysis to health equipment scenarios (heartbeat/EKG) to applications of a decibal indicator or light sensor. Output projects pretty much fall into the printing and robotic’s categories. Do robots controlled by algorithms and mathematical formulas (gnu-plot?) beyond just a simple set of commands spark a student’s interest? I thought I read something at oreillynet.com about Python Lego Mindstorms project. Has it gone anywhere? Best Regards, Dean Goodmanson _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From fig@monitor.net Mon Jul 2 14:06:38 2001 From: fig@monitor.net (Stephen R. Figgins) Date: Mon, 02 Jul 2001 06:06:38 -0700 Subject: [Edu-sig] Post request and Dead-link note In-Reply-To: Your message of "Sun, 01 Jul 2001 20:36:26 -0000." Message-ID: <200107021306.f62D6cI02783@localhost.localdomain> Dean Goodmanson writes: > I thought I read something at oreillynet.com about Python Lego Mindstorms > project. Has it gone anywhere? That was my article. The closest you can get is python remote control of Lego mindstorms. Python can't squeeze into the Mindstorms brick. I had thought you might be able to use Jython to program for LeJos, the Java Lego OS, but code compiled with Jython requires a hefty helper class that won't fit on the brick either. Jonathan Pennington proposed to create an inexpensive robot that ran Linux and used Python as a programming language. You can find his project on Sourceforge: http://eggo.sourceforge.net/ -Stephen From feiguin@magnet.fsu.edu Mon Jul 2 17:03:52 2001 From: feiguin@magnet.fsu.edu (Adrian Feiguin) Date: Mon, 2 Jul 2001 12:03:52 -0400 (EDT) Subject: [Edu-sig] gtkLeastSquares.py Message-ID: Hi everybody, I'm the author of SciGraphica (http://scigraphica.sourceforge.net), an application for scientific graphics and data analysis that uses Python and Numpy. Among other things, it features spreadheets that can contain Python data, like formulas. The Python stuff was mainly done by Conrad Steenberg, because I don't have much experience, specially embedding Python into C. However, I decided to get started this weekend because we needed badly a GUI for non-linear least squares fits. The result is gtkLeastSquares.py, which is attached below. It's going to be distributed with SG, but it works independently and needs gtk.py and Scientific. Basically it is a gtk GUI for Scientific.Functions.LeastSquares. I'm quite satisfied with the result, considering that I'm a newbie ;-) I'm writting because I'd like to have some feedback, and people interested in contributing. The code is still immature, and needs enhancements, like user defined functions and parameters (either editing the existing in the GUI, or adding new ones interactively). I still have to learn. It is very simple, and easy to use. You'll find the code below, with an example at the bottom of the file. I hope you like it. All comments, and suggestions are very welcome (as well as contributors ;-) Thank you, -------------- Cut here ---------------------- # # gtkLeastSquares.py : GUI for the module Scientific.Functions.LeastSquares # Implementation of the Levenberg-Marquardt algorithm for general # non-linear least-squares fits. # # Copyright (C) 2001 Adrian E. Feiguin # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. # from string import * from gtk import * from Numeric import * from Scientific.Functions.LeastSquares import * from Scientific.Functions.FirstDerivatives import * def fit_linear(parameters, values): a, b = parameters x = values return (a + b * x) def fit_cuadratic(parameters, values): a, b, c, x0 = parameters x = values return(a + b * (x - x0) + c * (x - x0)**2) return def fit_gauss(parameters, values): y0, x0, a, w = parameters x = values return(y0 + a * exp(-2*(x-x0)**2/w**2)) return def fit_lorentz(parameters, values): x0, y0, a, b = parameters x = values return(y0 + 2*a/pi * w / (4 * (x - x0)**2 + w**2)) return def fit_boltzman(parameters, values): x0, a1, a2, dx = parameters x = values return((a1 - a2)/(1 + exp((x - x0)/dx)) + a2) def fit_logistic(parameters, values): x0, a1, a2, p = parameters x = values return((a1 - a2)/(1 + (x/x0)**p) + a2) def fit_expdecay(parameters, values): x0, y0, a, t = parameters x = values return(y0 + a * exp(-(x - x0)/t)) def fit_expgrow(parameters, values): x0, y0, a, t = parameters x = values return(y0 + a * exp((x - x0)/t)) def fit_expassoc(parameters, values): y0, a1, t1, a2, t2 = parameters x = values return(y0 + a1 * (1 + exp(-x/t1)) + a2 * (1 + exp(-x/t2))) def fit_hyperbl(parameters, values): p1, p2 = parameters x = values return(p1 * x/ (p2 + x)) def fit_pulse(parameters, values): x0, y0, a, t1, t2 = parameters x = values return(y0 + a * (1 + exp(-(x - x0)/t1)) * exp(-(x - x0)/t2)) def fit_rational0(parameters, values): a, b, c = parameters x = values return((b + c*x)/(1 + a*x)) def fit_sine(parameters, values): x0, a, w = parameters x = values return(a * sin(pi*(x - x0)/w)) def fit_gaussamp(parameters, values): x0, y0, a, w = parameters x = values return(y0 + a * exp(-(x - x0)**2/(2*w**2))) def fit_allometric(parameters, values): a, b = parameters x = values return(a * x**b) fit_linear_dic = { "Doc" : "Linear Function", "Exp" : "y = a + b * x", "Par" : ("a", "b"), "NumPar" : 2, "IVar" : "x", "DVar" : "y", "Function" : fit_linear } fit_cuadratic_dic = { "Doc" : "Cuadratic Function", "Exp" : "y = a + b * (x - x0) + c * (x - x0)**2", "Par" : ("a", "b", "c", "x0"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_cuadratic } fit_gauss_dic = { "Doc" : "Amplitude version of Gaussian Function", "Exp" : "y = y0 + a * exp(-2*(x-x0)**2/w**2)", "Par" : ("x0", "y0", "a", "w"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_gauss } fit_lorentz_dic = { "Doc" : "Lorentzian Peak Function", "Exp" : "y = y0 + 2*a/pi * w / (4 * (x - x0)**2 + w**2)", "Par" : ("x0", "y0", "a", "w"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_lorentz } fit_boltzman_dic = { "Doc" : "Boltzman Function: sigmoidal curve", "Exp" : "y = (a1 - a2)/(1 + exp((x - x0)/dx)) + a2", "Par" : ("x0", "a1", "a2", "dx"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_boltzman } fit_logistic_dic = { "Doc" : "Logistic dose/response", "Exp" : "y = (a1 - a2)/(1 + (x/x0)**p) + a2", "Par" : ("x0", "a1", "a2", "p"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_logistic } fit_expdecay_dic = { "Doc" : "Exponential Decay", "Exp" : "y = y0 + a * exp(-(x - x0)/t)", "Par" : ("x0", "y0", "a", "t"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_expdecay } fit_expgrow_dic = { "Doc" : "Exponential Growth", "Exp" : "y = y0 + a * exp((x - x0)/t)", "Par" : ("x0", "y0", "a", "t"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_expgrow } fit_expassoc_dic = { "Doc" : "Exponential Associate", "Exp" : "y = y0 + a1 * (1 + exp(-x/t1)) + a2 * (1 + exp(-x/t2))", "Par" : ("y0", "a1", "t1", "a2", "t2"), "NumPar" : 5, "IVar" : "x", "DVar" : "y", "Function" : fit_expassoc } fit_hyperbl_dic = { "Doc" : "Hyperbola Function", "Exp" : "y = p1 * x/ (p2 + x)", "Par" : ("p1", "p2"), "NumPar" : 2, "IVar" : "x", "DVar" : "y", "Function" : fit_hyperbl } fit_pulse_dic = { "Doc" : "Pulse Function", "Exp" : "y = y0 + a * (1 + exp(-(x - x0)/t1)) * exp(-(x - x0)/t2)", "Par" : ("y0", "a", "t1", "t2"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_pulse } fit_rational0_dic = { "Doc" : "Rational Function , type 0", "Exp" : "y = (b + c*x)/(1 + a*x)", "Par" : ("a", "b", "c"), "NumPar" : 3, "IVar" : "x", "DVar" : "y", "Function" : fit_rational0 } fit_sine_dic = { "Doc" : "Sine Function", "Exp" : "y = a * sin(pi*(x - x0)/w)", "Par" : ("a", "x0", "w"), "NumPar" : 3, "IVar" : "x", "DVar" : "y", "Function" : fit_sine } fit_gaussamp_dic = { "Doc" : "Amplitude version of Gaussian Peak Function", "Exp" : "y = y0 + a * exp(-(x - x0)**2/(2*w**2))", "Par" : ("x0", "y0", "a", "w"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_gaussamp } fit_allometric_dic = { "Doc" : "Classical Freundlich Model", "Exp" : "y = a * x**b", "Par" : ("a", "b"), "NumPar" : 4, "IVar" : "x", "DVar" : "y", "Function" : fit_allometric } functions = { "Linear" : fit_linear_dic, "Cuadratic" : fit_cuadratic_dic, "Gauss" : fit_gauss_dic, "Lorentz" : fit_lorentz_dic, "Boltzman" : fit_boltzman_dic, "Logistic" : fit_logistic_dic, "ExpDecay" : fit_expdecay_dic, "ExpGrow" : fit_expgrow_dic, "ExpAssoc" : fit_expassoc_dic, "Hyperbl" : fit_hyperbl_dic, "Pulse" : fit_pulse_dic, "Rational0" : fit_rational0_dic, "Sine" : fit_sine_dic, "GaussAmp" : fit_gaussamp_dic, "Allometric" : fit_allometric_dic } def fit(data): main_window = GtkWindow() main_window.set_title("Curve Fitting") main_window.set_border_width(5) main_window.connect("destroy", mainquit) main_window.connect("delete_event", mainquit) main_box = GtkVBox(FALSE, 5) main_window.add(main_box) main_frame = GtkFrame("Select Function") main_box.pack_start(main_frame) table = GtkTable(7, 4, FALSE) table.set_col_spacings(10) table.set_row_spacings(5) table.set_border_width(5) main_frame.add(table) swindow = GtkScrolledWindow() swindow.set_policy(POLICY_AUTOMATIC, POLICY_AUTOMATIC) swindow.set_usize(120, 100) table.attach(swindow, 0, 1, 0, 6) clist = GtkCList(1) swindow.add(clist) table.attach(GtkVSeparator(), 1, 2, 0, 6) text = map(lambda i: str(i), range(20)) k = functions.keys() k.sort() for i in k: text[0] = i clist.append(text) label = GtkLabel("Exp:") label.set_alignment(1., .5) table.attach(label, 2, 3, 0, 1) fentry = GtkEntry() # fentry.set_editable(FALSE) table.attach(fentry, 3, 4, 0, 1) label = GtkLabel("Number of Param:") label.set_alignment(1., .5) table.attach(label, 2, 3, 1, 2) nspin = GtkSpinButton(GtkAdjustment(0, 0, 8, 1, 8, 0), 0, 0) nspin.set_editable(FALSE) nspin.set_state(STATE_INSENSITIVE) table.attach(nspin, 3, 4, 1, 2) label = GtkLabel("Param:") label.set_alignment(1., .5) table.attach(label, 2, 3, 2, 3) pentry = GtkEntry() pentry.set_editable(FALSE) pentry.set_state(STATE_INSENSITIVE) table.attach(pentry, 3, 4, 2, 3) label = GtkLabel("Independent Var:") label.set_alignment(1., .5) table.attach(label, 2, 3, 3, 4) iventry = GtkEntry() iventry.set_editable(FALSE) iventry.set_state(STATE_INSENSITIVE) table.attach(iventry, 3, 4, 3, 4) label = GtkLabel("Dependent Var:") label.set_alignment(1., .5) table.attach(label, 2, 3, 4, 5) dventry = GtkEntry() dventry.set_editable(FALSE) dventry.set_state(STATE_INSENSITIVE) table.attach(dventry, 3, 4, 4, 5) action_area = GtkHButtonBox() action_area.set_layout(BUTTONBOX_END) action_area.set_spacing(5) main_box.pack_start(action_area) fit_button = GtkButton("Fit") action_area.pack_start(fit_button) close_button = GtkButton("Close") action_area.pack_start(close_button) lframe = GtkFrame() lframe.set_shadow_type(SHADOW_IN) main_box.pack_start(lframe) explabel = GtkLabel("Choose a Fitting Function") lframe.add(explabel) # CALLBACK FUNCTIONS def select_function(_clist, row, col, event, functions = functions, label = explabel, fentry = fentry, pentry = pentry, nspin = nspin, iventry = iventry, dventry = dventry): k = _clist.get_text(row, col) f = functions[k] label.set_text(f["Doc"]) fentry.set_text(f["Exp"]) nspin.set_value(f["NumPar"]) iventry.set_text(f["IVar"]) dventry.set_text(f["DVar"]) s = "" for i in f["Par"]: s = s + i + ", " pentry.set_text(s[:len(s)-2]) def open_fit_dialog(_button, functions = functions, clist = clist, data = data): a = clist.__getattr__("selection") k = clist.get_text(a[0], 0) f = functions[k] param = (1, 1) fit_dialog(f, data) # CONNECT OBJECTS clist.connect("select_row", select_function) fit_button.connect("clicked", open_fit_dialog) close_button.connect("clicked", main_window.destroy) clist.select_row(0, 0) main_window.show_all() mainloop() def fit_dialog(f, data): main_window = GtkWindow() main_window.set_title("Fit") main_window.set_border_width(5) main_window.connect("destroy", mainquit) main_window.connect("delete_event", mainquit) table = GtkTable(len(f["Par"])+3, 2, FALSE) table.set_col_spacings(10) table.set_row_spacings(5) main_window.add(table) table.attach(GtkLabel("Variable"), 0, 1, 0, 1) table.attach(GtkLabel("Value"), 1, 2, 0, 1) table.attach(GtkHSeparator(), 0, 2, 1, 2) r = 2 entries = [] for i in f["Par"]: # check = GtkCheckButton(i+":") # table.attach(check, 0, 1, r, r+1) table.attach(GtkLabel(i+":"), 0, 1, r, r+1) entry = GtkEntry() entries = entries + [entry] entry.set_text("0.0") table.attach(entry, 1, 2, r, r+1) r = r + 1 table.attach(GtkHSeparator(), 0, 2, r, r + 1) r = r + 1 table.attach(GtkLabel("Chi_Sqr:"), 0, 1, r, r + 1) err_entry = GtkEntry() table.attach(err_entry, 1, 2, r, r + 1) r = r + 1 table.attach(GtkHSeparator(), 0, 2, r, r + 1) def run_fit(_button, f = f, data = data, entries = entries, err_entry = err_entry): n = 0 p = () for i in entries: s = entries[n].get_text() p = p + (atof(s),) n = n + 1 fit, error = leastSquaresFit(f["Function"], p, data) n = 0 for i in entries: entries[n].set_text(str(fit[n])) n = n + 1 err_entry.set_text(str(error)) # print "Fitted parameters: ", fit # print "Fit error: ", error return action_area = GtkHButtonBox() action_area.set_layout(BUTTONBOX_SPREAD) action_area.set_spacing(5) run_button = GtkButton("Run") close_button = GtkButton("Close") action_area.pack_start(run_button) action_area.pack_start(close_button) table.attach(action_area, 0, 2, r + 1, r + 2) # CONNECT OBJECTS run_button.connect("clicked", run_fit) close_button.connect("clicked", main_window.destroy) main_window.show_all() mainloop() # Test for linear fit: # # from gtkLeastSquares import * # data = [ (0., 0.), (1., 1.1), (2., 1.98), (3., 3.05) ] # fit(data) From Brent.Burley@disney.com Mon Jul 2 17:49:08 2001 From: Brent.Burley@disney.com (Brent Burley) Date: Mon, 02 Jul 2001 09:49:08 -0700 Subject: [Edu-sig] OT - Disney Learning - again References: Message-ID: <3B40A604.ED177B@fa.disney.com> ART wrote: > ... > A new ad/announcement for Disney Learning > Partnership with a URL ref - www.disneylearning.com > > December 10 - Dr. Alan Kay. It was December 10, *1999* - > and is an *upcoming* event on the schedule. Probably > in fact the one I looked at some time ago. > > *Today* they spent serious money promoting this > hopelessly neglected site. What is the agenda here??????? First let me say that I don't speak for Disney and I have no direct information about disneylearning.com. >From what I understand, Kay was recruited 5 years ago specifically to promote Squeak and computer education for kids. This was probably part of Disney's big Internet push back when it seemed that everything and everyone was going online. According to a New York Times article on 6/13/2001, Alan Kay is leaving Disney and taking the Squeak group with him as "Disney has scaled back a number of its ambitious Internet plans." Kay and his team reportedly volunteered for the recent company-wide layoff. I'm not sure what relationship Kay had with disneylearning.com. It seems the advisory council is made up entirely of people outside of Disney and primarily from various universities. They seemed to have made a number of grants in 1999 but nothing since then. Curiously, squeak.org hasn't had much attention since 1999 either. Witness the link "Entering 2000" at http://squeak.org/about! Brent From Jason Cunliffe" Message-ID: <001701c10345$bcf3b700$c3090740@megapathdsl.net> "Arthur Siegel" wrote: > A new ad/announcement for Disney Learning > Partnership with a URL ref - www.disneylearning.com ..yeah.. OT++ anecdote: I had a brush with EduDisney around 1993. An enthusiastic young project manager Disney came to us [a group of 3 = programmer+designer+artist] to ask for our ideas for amazing new Disney educational mega-scheme,. They wanted ideas for interfaces, architecture etc.. Vague ambitious stuff. Despite our basic suspicions of Disney it was fun to apply our creative energies to the problem. Some meetings, some whiteboarding, more brainstorming, background reading and research, some firming ideas and then launched into 3D to model some avatar/agent 'characters' which they had asked for a key part of the interface. Disney viewed it as giant publishing media engulfing type project. We saw it as a challenging way to abstract and focus functions, by developing them as if they were characters, but really distinct modular Engines underneath embodying some powerful ideas about learning, relationships etc... That was the exciting part. Nice to get paid to dream and design about such things. They liked [no "loved"] the first draft ["thes is gonna be great!! - you guys are amazing..."] - some revisions, more seed money... another presentation hastily prepared before our project manager flew to LA to pitch it to his bosses. Some wired, slightly paranoid emails and phone calls asking us to amplify certain ideas.. then embarrassed silence and later demi-explanations. It emerged his boss[es] had hired several people like him, all at the same time, all boosted to go on the same idealistic mission. Then they let various factors including a big dose of politics resolve the next selection. He was frustrated and chagrined. We were a little disappointed, a little relieved, and not much surprised. I have heard since that this is strategy Disney uses - to pitch project managers against each other just like many ad-agencies do to keep everyone hopping.. They are very skilled at hiring all kinds of talented people to dream big.. later appropriate[rob] and merge[remix] among the guinea-pig projects. The are also famous for shelving ideas as preventive insurance against others. As I remember, Alan Kay is brilliant.. I hope he thrives and survives his Disney days. Don't be surprised if he moves on before long.. especially if the project has been dangling publicly like this. ./Jason From feiguin@magnet.fsu.edu Mon Jul 2 22:43:11 2001 From: feiguin@magnet.fsu.edu (Adrian Feiguin) Date: Mon, 2 Jul 2001 17:43:11 -0400 (EDT) Subject: [Edu-sig] ANNOUNCE: SciGraphica-0.7.0 Message-ID: I'm pleased to announce the new release of Scigraphica with bugfixes and enhancements. Among other things, embedding images is now possible, as well as setting background images for the plots. Clipboard for plots: copy a plot, and paste it on a different plot window. Improved PostScript and WYSIWYG. It includes pysga.py, a Python module for interacting with plots and worksheets from terminal. New scheme for storing numerical data in worksheets. Examples are included. Scigraphica is a powerful tool for scientific graphics and data analysis. It pretends to be a clone of the popular commercial (and expensive) application "Microcal Origin". It fully supplies plotting features for 2D, 3D and polar charts. The aim is to obtain a fully-featured, cross-plattform, user-friendly, self-growing scientific application. It is free and open-source, released under the GPL license. Main features: -You can plot functions and manipulate data in worksheets. -You can open several worksheets and plots and work with them at the same time. -The plots are fully configurable using a control panel dialog. -The look and feel is completely WYSIWYG. -Publication quality PostScript output. -You can interact with the plots double-clicking, dragging and moving objects with the mouse. -Export/Import features in XML format. -You can insert Python expressions in the worksheets. -Terminal with command-line Python interface for interacting with plots and worksheets URL: http://scigraphica.sourceforge.net Enjoy! The SciGraphica Team.- ------------------------------------------------------------------------ TODO for sg-0.8.0: sg-0.8.0 will have a completely different structure, more modular, built ontop of reusable libraries. SGplot, SGworksheet, SGlayer, and SGdataset will be GtkWidgets and part of a shareable library, that could be used by other applications, and from Python. From ajs@ix.netcom.com Tue Jul 3 03:06:26 2001 From: ajs@ix.netcom.com (Arthur Siegel) Date: Mon, 2 Jul 2001 22:06:26 -0400 Subject: [Edu-sig] re: OT - Disney Learning - again Message-ID: <001f01c10364$c516c020$a9e1fea9@carol> >From what I understand, Kay was recruited 5 years ago specifically to >promote Squeak and computer education for kids. This was probably part >of Disney's big Internet push back when it seemed that everything and >everyone was going online. Edu-sig has demonstrated that how one defines "computer education for kids" comes in many flavors. Happens my flavor and what I sense will inevitably come out of Disney are not very reconcilable. Hoping for a level playing field would not be unrealistic. But a distortion of the field on the scale that Disney is able to accomplish - $billions if they are so inclined - is not something I can calmly contemplate. >According to a New York Times article on 6/13/2001, Alan Kay is leaving >Disney and taking the Squeak group with him as "Disney has scaled back a >number of its ambitious Internet plans." Kay and his team reportedly >volunteered for the recent company-wide layoff. That's good news. If Alan Kay wants to pursue his ideas on the merits, great. The Disney thing I feared was not playing fair. And I'm sure he had to be embarrassed enough on his own account at some level. >I'm not sure what relationship Kay had with disneylearning.com. It >seems the advisory council is made up entirely of people outside of >Disney and primarily from various universities. They seemed to have >made a number of grants in 1999 but nothing since then. Small grants - puny relative to the amount they have spent announcing that they have made them. The fact is that a few bucks one can get the attention of the entire K-12 establishment. Any reasonable sense of decorum and corporate responsibility has been thrown to the wind by Disney in handling this. Because they can reasonably be seen to be self-interested - all the more reason to handle it with dignity. But a few $billion in the bank, does breed arrogance and does make friends. There is no reason I should feel like I am pissing in the wind by expressing outrage. Nonetheless, I do. ART From goodmansond@hotmail.com Tue Jul 3 03:51:01 2001 From: goodmansond@hotmail.com (Dean Goodmanson) Date: Tue, 03 Jul 2001 02:51:01 -0000 Subject: [Edu-sig] Post request and Dead-link note - FOLLOW-UP Message-ID: Stephen (and Edu-sig regulars), Thank you for your reply. I revisited your Oreilly post and found I didn't read enough before posting. I've since drifted through the archives and found that the robotics and interaction portion of my message have been well discussed. The use of physical world interaction and linguistics discussion of a computer language are also well covered. I've found the discussions of teaching math and programming rather mind-blowing. Please forgive my less than detailed, redundant topiced, testimonial post. It appears my application has preceded my analysis. As far as my off-the mark subject line, the original subject was in an email to the list admin. -Dean _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From ajs@ix.netcom.com Tue Jul 3 12:29:38 2001 From: ajs@ix.netcom.com (Arthur Siegel) Date: Tue, 3 Jul 2001 07:29:38 -0400 Subject: [Edu-sig] OT - Disney Learning - again References: <000901c101b5$d2630e60$a9e1fea9@carol> <001701c10345$bcf3b700$c3090740@megapathdsl.net> Message-ID: <001e01c103b3$729548e0$a9e1fea9@carol> > Despite our basic suspicions of Disney it was fun to apply our creative > energies to the problem. Some meetings, some whiteboarding, more > brainstorming, background reading and research, some firming ideas and then > launched into 3D to model some avatar/agent 'characters' which they had > asked for a key part of the interface. No offense Jason - but this sounds exactly like the direction I would expect to see Disney go. Sort of a video game approach. New media for a new education for the new econcomy. Bah humbug. ART From delza@alliances.org Wed Jul 4 06:32:14 2001 From: delza@alliances.org (Dethe Elza) Date: Tue, 03 Jul 2001 22:32:14 -0700 Subject: [Edu-sig] Lesson plan collection Message-ID: >From time to time folks post their lesson plans to this list, or at least the availability of such. Has anyone been collecting these in one location? Is there a repository of lesson plans and materials for teaching python? Anyone else think this is a good idea? My motives are purely selfish -- I'm getting ready to propose a continuing education course, or series of courses, to a couple of local colleges and I want to do as little work as possible %-) I want to cover Python, of course, and tie it in with the web, xml, and gui development. Any leads would be appreciated. -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) From wesc@deirdre.org Wed Jul 4 09:06:51 2001 From: wesc@deirdre.org (Wesley Chun) Date: Wed, 4 Jul 2001 01:06:51 -0700 (PDT) Subject: [Edu-sig] Lesson plan collection In-Reply-To: Message-ID: On Tue, 3 Jul 2001, Dethe Elza wrote: > From time to time folks post their lesson plans to this list, or at least > the availability of such. Has anyone been collecting these in one location? > Is there a repository of lesson plans and materials for teaching python? > Anyone else think this is a good idea? > > My motives are purely selfish -- I'm getting ready to propose a continuing > education course, or series of courses, to a couple of local colleges and I > want to do as little work as possible %-) I want to cover Python, of > course, and tie it in with the web, xml, and gui development. dethe, i teach a continuing education course for UC Santa Cruz (Extension). feel free to copy the course info for the last class i taught back in Fall 2000. here is the course description: http://melvin.ucsc-extension.edu/~wesc/002e44/002e44cd.htm this is the course web page where students can get access to the homework assignments, sample code, etc.: http://melvin.ucsc-extension.edu/~wesc/002e44/ let me know when you find course material on XML and SQL... i need those purely for selfish reasons as well! :-) -wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Silicon Valley-SF Bay Area Python users group: http://baypiggies.org "Core Python Programming", Prentice Hall PTR, December 2000 http://starship.python.net/crew/wesc/cpp/ wesley.j.chun :: wesc@baypiggies.org cyberweb.consulting :: silicon.valley, ca http://www.roadkill.com/~wesc/cyberweb/ From wesc@deirdre.org Wed Jul 4 09:20:41 2001 From: wesc@deirdre.org (Wesley Chun) Date: Wed, 4 Jul 2001 01:20:41 -0700 (PDT) Subject: [Edu-sig] Lesson plan collection In-Reply-To: Message-ID: i should also note that by adding in "Extra"s such as MT, XML, networking (sockets), GUI/Tkinter, etc., results in a very long course... so much material that i've given some thought to split all this stuff up into two separate courses, i.e., Intro to Python and Advanced Python Pro- gramming. there is also some consensus, in parallel, to do something similar to the Core Python Programming book, similar to what Prentice Hall did for another book in the Core serires, Core Java... but that won't be until *after* i've recovered (read: 2.3 timeframe). ;-) -wesley On Wed, 4 Jul 2001, Wesley Chun wrote: > On Tue, 3 Jul 2001, Dethe Elza wrote: > > > From time to time folks post their lesson plans to this list, or at least > > the availability of such. Has anyone been collecting these in one location? > > Is there a repository of lesson plans and materials for teaching python? > > Anyone else think this is a good idea? > > > > My motives are purely selfish -- I'm getting ready to propose a continuing > > education course, or series of courses, to a couple of local colleges and I > > want to do as little work as possible %-) I want to cover Python, of > > course, and tie it in with the web, xml, and gui development. > > > dethe, > > i teach a continuing education course for UC Santa Cruz (Extension). > feel free to copy the course info for the last class i taught back > in Fall 2000. here is the course description: > > http://melvin.ucsc-extension.edu/~wesc/002e44/002e44cd.htm > > this is the course web page where students can get access to the > homework assignments, sample code, etc.: > > http://melvin.ucsc-extension.edu/~wesc/002e44/ > > let me know when you find course material on XML and SQL... > i need those purely for selfish reasons as well! :-) > > -wesley > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Silicon Valley-SF Bay Area Python users group: http://baypiggies.org > > "Core Python Programming", Prentice Hall PTR, December 2000 > http://starship.python.net/crew/wesc/cpp/ > > wesley.j.chun :: wesc@baypiggies.org > cyberweb.consulting :: silicon.valley, ca > http://www.roadkill.com/~wesc/cyberweb/ > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > From mats@laplaza.org Wed Jul 4 10:49:33 2001 From: mats@laplaza.org (Mats Wichmann) Date: Wed, 04 Jul 2001 10:49:33 +0100 Subject: [Edu-sig] Lesson plan collection In-Reply-To: References: Message-ID: <5.1.0.14.1.20010704104452.00a9f9e0@laplaza.org> >let me know when you find course material on XML and SQL... >i need those purely for selfish reasons as well! :-) I've given some thought to starting to work up something in this area. I've thought about the DB bits, but not written anything; XML is just a dream, so I'm also looking for ideas. What I've got in the current course "belongs" to Learning Tree (if anyone cares, there's an outline at learningtree.com under course 430 which I won't repost here), but I don't mind sharing if I do end up producing anything outside of that framework. No promises that I'll ever actually write anything, tho!!!!! Mats From wilson@visi.com Wed Jul 4 16:09:45 2001 From: wilson@visi.com (Timothy Wilson) Date: Wed, 4 Jul 2001 10:09:45 -0500 (CDT) Subject: [Edu-sig] Lesson plan collection In-Reply-To: Message-ID: On Tue, 3 Jul 2001, Dethe Elza wrote: > >From time to time folks post their lesson plans to this list, or at least > the availability of such. Has anyone been collecting these in one location? > Is there a repository of lesson plans and materials for teaching python? > Anyone else think this is a good idea? I certainly think something like that is a good idea. I haven't come to any conclusions about how best to accomplish it though. Any ideas? -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.org W. St. Paul, MN | | http://slashdot.org wilson@visi.com | | http://linux.com From delza@alliances.org Wed Jul 4 16:23:38 2001 From: delza@alliances.org (Dethe Elza) Date: Wed, 04 Jul 2001 08:23:38 -0700 Subject: [Edu-sig] Lesson plan collection In-Reply-To: Message-ID: Thanks, Wesley! I teach a 4-hour high level intro to XML, the class notes are at: http://delza.alliances.org/xml Also an occasional class on programming XML, mainly using XSLT. There is no programming pre-requisite that I can rely on for this class. If I had my way I'd teach it as a follow-up to a basic XML class, but I just fill in when the regular instructor can't make it. Anyway, my notes are up at: http://delza.alliances.org/xsl Both pages have extensive links to other tutorials and presentations. As far as Python goes, I'm trying to get a handle on what's realistic to cover in a 6-8 week, 2-3 hours per week continuing ed class, given that attendees will have wildly varying previous knowledge (in most cases no programming at all). I know I won't be able to cover GUIs and network programming extensively, but I think giving the students a taste of that, even in a introductory class, is important. -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) From delza@alliances.org Wed Jul 4 16:29:00 2001 From: delza@alliances.org (Dethe Elza) Date: Wed, 04 Jul 2001 08:29:00 -0700 Subject: [Edu-sig] Lesson plan collection In-Reply-To: Message-ID: > I certainly think something like that is a good idea. I haven't come to any > conclusions about how best to accomplish it though. Any ideas? > > -Tim Well, some of the other SIGs have online repositories. We could start a SourceForge site or a Wiki with the purpose of housing a FAQ, examples repository, important pointers which crop up, tips for getting up to speed with the group, etc. Lesson plans could be an important part of this. Alternatively, we could add a section for storing (or pointing to) existing lesson plans on one of the related sites, either "Useless Python" or "Contagious Fun." In any case, once we've decided and put something up, we should petition the Powers That Be to add a link to the SIG page. -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) From wilson@visi.com Wed Jul 4 17:09:02 2001 From: wilson@visi.com (Timothy Wilson) Date: Wed, 4 Jul 2001 11:09:02 -0500 (CDT) Subject: [Edu-sig] Lesson plan collection In-Reply-To: Message-ID: On Wed, 4 Jul 2001, Dethe Elza wrote: > Well, some of the other SIGs have online repositories. We could start a > SourceForge site or a Wiki with the purpose of housing a FAQ, examples > repository, important pointers which crop up, tips for getting up to speed > with the group, etc. Lesson plans could be an important part of this. I was talking with another list member, Chris Smith, a couple weeks ago and we were trying to figure out a way to index our lesson plans. In a perfect world, a teacher (or student for that matter) would search a database for lessons that match a particular type of Python task. So let's say a teacher wanted to teach intermediate string manipulation. The database might return a link to a programming exercise like the Pig Latin translator one I wrote a couple weeks ago when Chris and I were discussing this. (http://www.isd197.org/sibley/staff/wilsont/python/piglatin_html) The problem, of course, is that it's nearly impossible to write a programming exercise that only "exercises" one aspect of programming. The database would probably need to employ some metadata about the lesson plan submissions listing all of the programming skills required by each exercise and some indication of the level of skill required. Something like Zope.org's concept of sharing links would probably work. The lesson plan submitor would only need to add the metadata and provide a link to the actual lesson plan. I've undoubtedly overlooked a lot here. It's been largely a stream of consciousness post. I'd appreciate any other ideas. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.org W. St. Paul, MN | | http://slashdot.org wilson@visi.com | | http://linux.com From aschmidt@nv.cc.va.us Thu Jul 5 12:13:19 2001 From: aschmidt@nv.cc.va.us (Schmidt, Allen J.) Date: Thu, 5 Jul 2001 07:13:19 -0400 Subject: [Edu-sig] Lesson plan collection Message-ID: <5CDFEBB60E7FD311B9E30000F6D6090688C10F@novamail1.nv.cc.va.us> So do you teach the Learning Tree course? Guido was promoting it a while back. I would love to take it but have not convinced anyone to pay for it yet. Allen -----Original Message----- From: Mats Wichmann [mailto:mats@laplaza.org] Sent: Wednesday, July 04, 2001 5:50 AM To: edu-sig@python.org Subject: Re: [Edu-sig] Lesson plan collection >let me know when you find course material on XML and SQL... >i need those purely for selfish reasons as well! :-) I've given some thought to starting to work up something in this area. I've thought about the DB bits, but not written anything; XML is just a dream, so I'm also looking for ideas. What I've got in the current course "belongs" to Learning Tree (if anyone cares, there's an outline at learningtree.com under course 430 which I won't repost here), but I don't mind sharing if I do end up producing anything outside of that framework. No promises that I'll ever actually write anything, tho!!!!! Mats _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig From urnerk@qwest.net Mon Jul 9 08:26:44 2001 From: urnerk@qwest.net (Kirby Urner) Date: Mon, 09 Jul 2001 00:26:44 -0700 Subject: [Edu-sig] Steps for making a Fractal with Python In-Reply-To: References: Message-ID: <4.2.0.58.20010709002609.00bce100@pop3.norton.antivirus> Steps to get a fractal (Mandelbrot) with Python: Used search engine to find: http://pathfinder.scar.utoronto.ca/~csca57/PIL_python.html Downloaded source code, saved as fractal.py, along with rainbow3.pal to same directory. rainbow3 is one of many palettes provided, and effectively colorizes the grayscale fractal using im.putpalette(pal, 'RGB'). Had latest PIL (Python Imaging Library) installed earlier, from http://www.secretlabs.com/products/pil/index.htm In DOS box (WinME), entered: D:\...> ..\python fractal.py "myfractal.gif" "rainbow3.pal" (initial ..\ because python.exe is in directory above the subdirectory where launching. Got a warning about some PIL module using nested scopes in a lambda, so added: from __future__ import nested_scopes to the top of the copied fractal.py source code. This fixed the problem. After a short time (fast computer), myfractal.gif was available for viewing. The picture resembles the one shown on the web page. The source defines an Image then uses im.putpixel((i,j),value) in a loop through all (i,j) image coordinates, to each of which there corresponds a complex number, which feeds into a special loop and either diverges or converges after n iterations. Note: I don't quite see why they coders import Tkinter. If I comment that out and import sys instead, it runs just fine. Maybe there was some plan to display the GIF at the end. As is, you need to pull up your GIF in a standard viewer. Kirby From Arthur_Siegel@rsmi.com Mon Jul 9 17:01:56 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Mon, 9 Jul 2001 11:01:56 -0500 Subject: [Edu-sig] re: Steps for making a Fractal with Python Message-ID: <0081643C.N22121@rsmi.com> Kirby writes - >Steps to get a fractal (Mandelbrot) with Python: You might also look at some demo code that ships with PyOpenGL: >From the source header (demos\dek\MandelImage.py) #!/usr/bin/env python ## This isn't really a PyOpenGL demo, but it's a nice ## example of how Numeric, Tkinter, and PIL can be used ## together to create all sorts of images. ## In this case, it's the Mandelbrot set. ## i used the Numerical python text example, but modified it to ## work with PIL PyOpenGL, BTW, is getting better and better. Version2.0 which is out in beta, will be a pretty complete SWIG of the entire API and the major extensioins. And great care seems to be being paid to distribution\install issues. On Windows, at least, the no brainer install works great. Recommended fun for all ages. ART From pdx4d@teleport.com Mon Jul 9 17:25:12 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 09 Jul 2001 09:25:12 -0700 Subject: [Edu-sig] re: Steps for making a Fractal with Python In-Reply-To: <0081643C.N22121@rsmi.com> Message-ID: <4.2.0.58.20010709092203.00bd5df0@pop3.norton.antivirus> > >You might also look at some demo code that ships with >PyOpenGL: Grabbed the latest OpenGL. Thanks for the update. Did this fractal demo actually work for you? On my machine, I get a blank Tk box but no image -- no error messages either. That's when either clicking on the program in Explorer or when doing Ctrl-F5 with the source open in a window. Any clues? Kirby From Arthur_Siegel@rsmi.com Mon Jul 9 19:08:50 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Mon, 9 Jul 2001 13:08:50 -0500 Subject: [Edu-sig] re: Steps for making a Fractal with Python Message-ID: <008178AD.N22121@rsmi.com> >Did this fractal demo actually work for you? On my >machine, I get a blank Tk box but no image -- no error >messages either. That's when either clicking on the >program in Explorer or when doing Ctrl-F5 with the >source open in a window. Any clues? See what you mean. Its old code, probably incompatible somehow with newer PIL or TK. But to see the image, you can add self.im.save("mandel.gif") to 'def creatImagef', and pull up the gif. I changed w and h params to 800 to make the gif large enough to be interesting. ART From jason@crash.org Mon Jul 9 21:41:16 2001 From: jason@crash.org (Jason L. Asbahr) Date: Mon, 9 Jul 2001 15:41:16 -0500 Subject: [Edu-sig] Nice Old Minsky Paper In-Reply-To: <008178AD.N22121@rsmi.com> Message-ID: This surfaced on Slashdot today, and it made me think of you guys: http://www.ai.mit.edu/people/minsky/papers/Logoworks.html Cheers, Jason :-) PS -- If anyone is planning on attending the O'Reilly Open Source conference this month, I'll be giving a talk on massively multiplayer games and Python. I think edu and gaming goes together like peanut butter and jelly. :-) ("Learning Through Simulation" is another way to put it...) From Arthur_Siegel@rsmi.com Mon Jul 9 23:50:05 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Mon, 9 Jul 2001 17:50:05 -0500 Subject: [Edu-sig] Hofstadter, Escher via Python Message-ID: <0081A69F.N22121@rsmi.com> Doing a Wallpaper Group, Plane Tilings surf (good programming for artists material) and not surprisingly come across what looks like an interesting Python effort at: http://www.andrewcooke.free-online.co.uk/jara/bulli/index.html Will look at it more closely this evenings. ART From pdx4d@teleport.com Mon Jul 9 23:32:43 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 09 Jul 2001 15:32:43 -0700 Subject: [Edu-sig] Hofstadter, Escher via Python In-Reply-To: <0081A69F.N22121@rsmi.com> Message-ID: <4.2.0.58.20010709153141.00c87e60@pop3.norton.antivirus> > > >http://www.andrewcooke.free-online.co.uk/jara/bulli/index.html > >Will look at it more closely this evenings. > >ART Thanks Art. Worked well for me on first try, with no modifications, by clicking bulli.py in Windows Explorer (trying to Ctrl-F5 in IDLE begets the usual program termination issues). Kirby From dscherer@vysics.com Mon Jul 9 23:30:51 2001 From: dscherer@vysics.com (David Scherer) Date: Mon, 9 Jul 2001 18:30:51 -0400 Subject: [Edu-sig] Hofstadter, Escher via Python In-Reply-To: <0081A69F.N22121@rsmi.com> Message-ID: <005301c108c6$d2022fb0$8101a8c0@RABBIT> This has nothing to do with plane tilings, but this subject line reminded me of this, which I wrote a while ago while reading Hofstadter's "Godel, Escher, Bach." I'll throw it out here in case anyone finds it interesting: Hofstadter defines a language "BlooP" which permits only bounded loops, and therefore can express only "primitive recursive" functions. A test for the Goldbach property looks like this: DEFINE PROCEDURE "GOLDBACH?" [N]: BLOCK 0: BEGIN CELL(0) <= 2; LOOP AT MOST N TIMES: BLOCK 1: BEGIN IF {PRIME? [CELL(0)] AND PRIME? [MINUS [N, CELL(0)]]}, THEN: BLOCK 2: BEGIN OUTPUT <= YES; QUIT BLOCK 0; BLOCK 2: END CELL(0) <= CELL(0) + 1 BLOCK 1: END BLOCK 0: END After a while this language got on my nerves. It occurred to me that Python, restricted to using only 'for i in range(???):' for iteration, can express exactly the same kinds of functions as BlooP (and fails to express the same kinds of functions). Recursion is not allowed, of course. In Python, the above algorithm is considerably more terse and readable: def goldbach(N): for i in range(2, N-2): if prime(i) and prime(N-i): return 1 return 0 It would be nice to see the examples in GEB rewritten this way. The reason that non-primitive-recursive functions can't be expressed in this subset of Python is because, as in BlooP, the program has to decide how many times it may loop before it begins looping. Therefore every program is guaranteed to terminate. Separately, here's a "proof" of a very well-known theorem of computer science: >>> from oracles import halt >>> print halt.__doc__ halt(f) returns 1 if f() will return, and 0 otherwise >>> def yes(): ... return "yes" >>> yes() "yes" >>> halt(yes) 1 >>> def no(): ... while 1: ... pass >>> halt(no) 0 >>> def mu(): ... if halt(mu): ... while 1: ... pass >>> halt(mu) From gritsch@iue.tuwien.ac.at Tue Jul 10 08:12:22 2001 From: gritsch@iue.tuwien.ac.at (Markus Gritsch) Date: Tue, 10 Jul 2001 09:12:22 +0200 Subject: [Edu-sig] Steps for making a Fractal with Python References: <4.2.0.58.20010709002609.00bce100@pop3.norton.antivirus> Message-ID: <3B4AAAD6.E835E7B6@iue.tuwien.ac.at> This is a multi-part message in MIME format. --------------BFD45A5A87DC8AE4E557A208 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 S2lyYnkgVXJuZXIgd3JvdGU6DQoNCj4gVGhlIHNvdXJjZSBkZWZpbmVzIGFuIEltYWdlIHRo ZW4gdXNlcyBpbS5wdXRwaXhlbCgoaSxqKSx2YWx1ZSkNCj4gaW4gYSBsb29wIHRocm91Z2gg YWxsIChpLGopIGltYWdlIGNvb3JkaW5hdGVzLCB0byBlYWNoIG9mIHdoaWNoDQo+IHRoZXJl IGNvcnJlc3BvbmRzIGEgY29tcGxleCBudW1iZXIsIHdoaWNoIGZlZWRzIGludG8gYSBzcGVj aWFsDQo+IGxvb3AgYW5kIGVpdGhlciBkaXZlcmdlcyBvciBjb252ZXJnZXMgYWZ0ZXIgbiBp dGVyYXRpb25zLg0KDQpJIHRoaW5rIGRvaW5nIGFsbCB0aGUgbG9vcGluZyBmb3IgZXZlcnkg c2luZ2xlIGNvb3JkaW5hdGUgaW4gUHl0aG9uIG11c3QgYmUNCnF1aXRlIHNsb3cgY29tcGFy ZWQgdG8gZG9pbmcgaXQgaW4gQy4gIFNvbWUgbW9udGggYWdvLCB0aGVyZSB3YXMgYW4gaW50 ZXJlc3RpbmcNCm9wdGltaXphdGlvbiBvZiBhIE1hbmRlbGJyb3QtcHJvZ3JhbSBvbiB0aGUg d3hQeXRob24gbWFpbGluZyBsaXN0LiAgVGhlIHRyaWNrDQp3YXMgdG8gdXNlIE51bWVyaWMg dG8gcGVyZm9ybSBtYXRyaXgtbXVsdGlwbGljYXRpb25zIG9mIHRoZSAqd2hvbGUqIHBpY3R1 cmUsDQphbmQgdGFrZSBhIGxvb2sgYWZ0ZXIgZXZlcnkgbXVsdGlwbGljYXRpb24gd2hpY2gg cGl4ZWxzIGZ1bGZpbGxlZCB0aGUNCmNvbnZlcmdlbmNlLWNvbmRpdGlvbi4gIEhlcmUgaXMg dGhlIHJlbGV2YW50IGNvZGUsIHRoZSBmdWxsIHByb2dyYW0gaXMNCmF0dGFjaGVkLg0KDQog ICAgICAgIHdoaWxlIChpdGVyYXRpb25zIDwgc2VsZi5NQVhfSVRFUkFUSU9OUykgYW5kIGxl bihpX25vKToNCiAgICAgICAgICAgICMgZG8gdGhlIGNhbGN1bGF0aW9ucyBpbi1wbGFjZQ0K ICAgICAgICAgICAgTnVtZXJpYy5tdWx0aXBseSh6Xywgel8sIHpfKQ0KICAgICAgICAgICAg TnVtZXJpYy5hZGQoel8sIGNfLCB6XykNCiAgICAgICAgICAgIG92ZXJmbG93ID0gTnVtZXJp Yy5ncmVhdGVyX2VxdWFsKGFicyh6XyksIDIuMCkNCiAgICAgICAgICAgIG5vdF9vdmVyZmxv dyA9IE51bWVyaWMubG9naWNhbF9ub3Qob3ZlcmZsb3cpDQogICAgICAgICAgICAjIGdldCB0 aGUgaW5kaWNlcyB3aGVyZSBvdmVyZmxvdyBvY2N1cmVkDQogICAgICAgICAgICAjIyMjb3Zl cmZsb3dJbmRpY2VzID0gTnVtZXJpYy5jb21wcmVzcyhvdmVyZmxvdywgaV9ubykgIyBzbG93 ZXINCiAgICAgICAgICAgIG92ZXJmbG93SW5kaWNlcyA9IE51bWVyaWMucmVwZWF0KGlfbm8s IG92ZXJmbG93KSAjIGZhc3Rlcg0KICAgICAgICAgICAgIyBzZXQgdGhlIHBpeGVsIGluZGlj ZXMgdGhlcmUNCiAgICAgICAgICAgIGZvciBpZHggaW4gb3ZlcmZsb3dJbmRpY2VzOg0KICAg ICAgICAgICAgICAgIGRhdGFbaWR4XSA9IGl0ZXJhdGlvbnMNCiAgICAgICAgICAgICMgY29t cHV0ZSB0aGUgbmV3IGFycmF5IG9mIG5vbi1vdmVyZmxvdyBpbmRpY2VzDQogICAgICAgICAg ICBpX25vID0gTnVtZXJpYy5yZXBlYXQoaV9ubywgbm90X292ZXJmbG93KQ0KICAgICAgICAg ICAgIyB1cGRhdGUgdGhlIHRvZG8gYXJyYXlzDQogICAgICAgICAgICBjXyA9IE51bWVyaWMu cmVwZWF0KGNfLCBub3Rfb3ZlcmZsb3cpDQogICAgICAgICAgICB6XyA9IE51bWVyaWMucmVw ZWF0KHpfLCBub3Rfb3ZlcmZsb3cpDQogICAgICAgICAgICBpdGVyYXRpb25zID0gaXRlcmF0 aW9ucyArIDENCg0KDQpFbmpveSwgTWFya3VzDQoNCg== --------------BFD45A5A87DC8AE4E557A208 Content-Type: application/octet-stream; name="mandelbrot10.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mandelbrot10.py" IyEgL3Vzci9iaW4vZW52IHB5dGhvbiANCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIzk0eDc4IyMNCg0KIiIiDQpNYW5kZWxicm90IHByb2dyYW0sIGZvciBubyBwYXJ0aWN1 bGFyIHJlYXNvbi4NCg0KICAgICAgICBKb2huIEZhcnJlbGw6IGluaXRpYWwgdmVyc2lvbg0K ICAgICAgICAgIFJvYmluIER1bm46IGludHJvZHVjZWQgd3hJbWFnZS5TZXREYXRhIGluc3Rl YWQgb2Ygd3hCaXRtYXBGcm9tRGF0YQ0KICAgIElvbmVsIFNpbWlvbmVzY3U6IHVzZWQgdGhl IE51bWVyaWMgcGFja2FnZSwgYW5kIHJld3JvdGUgYWxsIG9mIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgY29tcHV0YXRpb24gYW5kIGRhdGEgZGlzcGxheWluZyBjb2RlDQpBbGV4 YW5kZXIgU21pc2hsYWpldjogc3VnZ2VzdGlvbnMgb24gb3B0aW1pc2luZyBsb29wcyBhbmQg ZHJhd2luZw0KICAgICAgTWFya3VzIEdyaXRzY2g6IGluLXBsYWNlIGNhbGN1bGF0aW9uIGlu IHRoZSBtYW5kZWxicm90IHdoaWxlIGxvb3ANCiAgICAgICBNaWtlIEZsZXRjaGVyOiBtaW5v ciBjaGFuZ2VzDQoiIiINCg0KaW1wb3J0IE51bWVyaWMNCmNsYXNzIE1hbmRlbGJyb3RHZW5l cmF0b3I6DQogICAgJycnU2xpZ2h0bHkgc2xvd2VyIG1hbmRlbGJyb3QgZ2VuZXJhdG9yLCB0 aGlzIG9uZSB1c2VzIGluc3RhbmNlIGF0dHJpYnV0ZXMgaW5zdGVhZCBvZg0KICAgIGdsb2Jh bHMgYW5kIHByb3ZpZGVzIGZvciAidGlsaW5nIiBkaXNwbGF5JycnDQogICAgZGVmIF9faW5p dF9fKCBzZWxmLCB3aWR0aD0yMDAsIGhlaWdodD0yMDAsIGNvb3JkaW5hdGVzPSgoLTIuMCwt MS41KSwoMS4wLDEuNSkpLA0KICAgICAgICAgICAgICAgICAgeGRpdmlzb3I9MCwgeWRpdmlz b3I9MCwgaXRlcmF0aW9ucyA9IDI1NSwgcmVkcmF3Q2FsbGJhY2s9Tm9uZSwNCiAgICAgICAg ICAgICAgICAgIHN0YXR1c0NhbGxiYWNrPU5vbmUgKToNCiAgICAgICAgc2VsZi53aWR0aCA9 IHdpZHRoDQogICAgICAgIHNlbGYuaGVpZ2h0ID0gaGVpZ2h0DQogICAgICAgIHNlbGYuY29v cmRpbmF0ZXMgPSBjb29yZGluYXRlcw0KICAgICAgICAjIyMgc2hvdWxkIGNoZWNrIGZvciBy ZW1haW5kZXJzIHNvbWV3aGVyZSBhbmQgYmUgYSBsaXR0bGUNCiAgICAgICAgIyBzbWFydGVy IGFib3V0IHZhbGlkIHJhbmdlcyBmb3IgZGl2aXNvcnMgKDEwMHMgb2YgZGl2aXNpb25zDQog ICAgICAgICMgaW4gYm90aCBkaXJlY3Rpb25zIG1lYW5zIDEwMDAwcyBvZiBjYWxjcykuLi4N CiAgICAgICAgaWYgbm90IHhkaXZpc29yOg0KICAgICAgICAgICAgeGRpdmlzb3IgPSAxICN3 aWR0aC81MCBvciAxDQogICAgICAgIGlmIG5vdCB5ZGl2aXNvcjoNCiAgICAgICAgICAgIHlk aXZpc29yID0gMTAgI2hlaWdodC81MCBvciAxDQogICAgICAgIHNlbGYueGRpdmlzb3IgPSB4 ZGl2aXNvcg0KICAgICAgICBzZWxmLnlkaXZpc29yID0geWRpdmlzb3INCiAgICAgICAgc2Vs Zi5yZWRyYXdDYWxsYmFjayA9IHJlZHJhd0NhbGxiYWNrDQogICAgICAgIHNlbGYuc3RhdHVz Q2FsbGJhY2sgPSBzdGF0dXNDYWxsYmFjayBvciBzZWxmLnByaW50U3RhdHVzDQogICAgICAg IHNlbGYuTUFYX0lURVJBVElPTlMgPSBpdGVyYXRpb25zDQogICAgICAgIHNlbGYuZGF0YSA9 IE51bWVyaWMuemVyb3Mod2lkdGgqaGVpZ2h0KQ0KICAgICAgICBzZWxmLmRhdGEuc2hhcGUg PSAod2lkdGgsIGhlaWdodCkNCiAgICAgICAgIyMjIFNldCB1cCB0aWxpbmcgaW5mbywgc2hv dWxkIHJlYWxseSBqdXN0IGRvIGFsbCB0aGUgc2V0dXAgaGVyZSBhbmQgdXNlIGENCiAgICAg ICAgIyMjIHJhbmRvbSBjaG9pY2UgdG8gZGVjaWRlIHdoaWNoIHRpbGUgdG8gY29tcHV0ZSBu ZXh0DQogICAgICAgIHNlbGYuY3VycmVudFRpbGUgPSAoLTEsMCkNCiAgICAgICAgc2VsZi50 aWxlRGltZW5zaW9ucyA9ICggd2lkdGgveGRpdmlzb3IsIGhlaWdodC95ZGl2aXNvciApDQog ICAgICAgIHNlbGYudGlsZVNpemUgPSAod2lkdGgveGRpdmlzb3IpKiAoaGVpZ2h0L3lkaXZp c29yKQ0KICAgICAgICAoeGEseWEpLCh4Yix5YikgPSBjb29yZGluYXRlcw0KICAgICAgICBz ZWxmLnhfc3RhcnRzID0gTnVtZXJpYy5hcmFuZ2UoIHhhLCB4YisoKHhiLXhhKS94ZGl2aXNv ciksICh4Yi14YSkveGRpdmlzb3IpDQogICAgICAgIHNlbGYueV9zdGFydHMgPSBOdW1lcmlj LmFyYW5nZSggeWEsIHliKygoeWIteWEpL3lkaXZpc29yKSwgKHliLXlhKS95ZGl2aXNvcikN CiAgICBkZWYgRG9BbGxUaWxlcyggc2VsZiApOg0KICAgICAgICB3aGlsZSBzZWxmLkRvVGls ZSgpOg0KICAgICAgICAgICAgcGFzcw0KICAgIGRlZiBEb1RpbGUoIHNlbGYsIGV2ZW50PU5v bmUgKToNCiAgICAgICAgJycnVHJpZ2dlcmVkIGV2ZW50IHRvIGRyYXcgYSBzaW5nbGUgdGls ZSBpbnRvIHRoZSBkYXRhIG9iamVjdCcnJw0KICAgICAgICB4X2luZGV4LCB5X2luZGV4ID0g c2VsZi5jdXJyZW50VGlsZQ0KICAgICAgICBpZiB4X2luZGV4IDwgc2VsZi54ZGl2aXNvci0x Og0KICAgICAgICAgICAgc2VsZi5jdXJyZW50VGlsZSA9IHhfaW5kZXgsIHlfaW5kZXggPSB4 X2luZGV4KzEsIHlfaW5kZXgNCiAgICAgICAgZWxpZiB5X2luZGV4IDwgc2VsZi55ZGl2aXNv ci0xOg0KICAgICAgICAgICAgc2VsZi5jdXJyZW50VGlsZSA9IHhfaW5kZXgsIHlfaW5kZXgg PSAwLCB5X2luZGV4KzENCiAgICAgICAgZWxzZToNCiAgICAgICAgICAgIGlmIHNlbGYucmVk cmF3Q2FsbGJhY2s6DQogICAgICAgICAgICAgICAgc2VsZi5yZWRyYXdDYWxsYmFjayggc2Vs Zi5kYXRhLCAwKQ0KICAgICAgICAgICAgcmV0dXJuIDANCiAgICAgICAgcHJpbnQgJ3N0YXJ0 aW5nIGl0ZXJhdGlvbicsIHhfaW5kZXgsIHlfaW5kZXgNCiAgICAgICAgY29vcmRzID0gKCAo c2VsZi54X3N0YXJ0c1t4X2luZGV4XSxzZWxmLnlfc3RhcnRzW3lfaW5kZXhdKSwNCiAgICAg ICAgICAgICAgICAgICAoc2VsZi54X3N0YXJ0c1t4X2luZGV4KzFdLHNlbGYueV9zdGFydHNb eV9pbmRleCsxXSksICApDQogICAgICAgIHBhcnQgPSBzZWxmLl90aWxlKCBjb29yZHMgKQ0K ICAgICAgICBwYXJ0LnNoYXBlID0gc2VsZi50aWxlRGltZW5zaW9uc1sxXSxzZWxmLnRpbGVE aW1lbnNpb25zWzBdDQogICAgICAgIHNlbGYuZGF0YVsoc2VsZi5oZWlnaHQvc2VsZi55ZGl2 aXNvcikqeV9pbmRleDooc2VsZi5oZWlnaHQvc2VsZi55ZGl2aXNvcikqDQogICAgICAgICAg ICAgICAgICAoeV9pbmRleCsxKSwNCiAgICAgICAgICAgICAgICAgIChzZWxmLndpZHRoL3Nl bGYueGRpdmlzb3IpKnhfaW5kZXg6KHNlbGYud2lkdGgvc2VsZi54ZGl2aXNvcikqDQogICAg ICAgICAgICAgICAgICAoeF9pbmRleCsxKSwgXSA9IHBhcnQNCiAgICAgICAgaWYgc2VsZi5y ZWRyYXdDYWxsYmFjazoNCiAgICAgICAgICAgIHNlbGYucmVkcmF3Q2FsbGJhY2soIHNlbGYu ZGF0YSwgMSApICMgdGhlcmUgbWF5IGJlIG1vcmUgdG8gZG8uLi4NCiAgICAgICAgcmV0dXJu IDENCiAgICBkZWYgcHJpbnRTdGF0dXMoc2VsZiwgKmFyZ3VtZW50cyApOg0KICAgICAgICBw YXNzICNwcmludCBhcmd1bWVudHMNCiAgICBkZWYgX3RpbGUoc2VsZiwgY29vcmRpbmF0ZXMp Og0KICAgICAgICAiIiJDYWxjdWxhdGUgYSBzaW5nbGUgdGlsZSdzIHZhbHVlIiIiDQojIyAg ICAgIHByaW50ICd0aWxlJw0KICAgICAgICAoYywgeikgPSBzZWxmLl9zZXR1cChjb29yZGlu YXRlcykNCiAgICAgICAgaXRlcmF0aW9ucyA9IDANCiAgICAgICAgc2l6ZSA9IHNlbGYudGls ZVNpemUNCiAgICAgICAgaV9ubyA9IE51bWVyaWMuYXJhbmdlKHNpemUpICAgICAgICMgbm9u LW92ZXJmbG93IGluZGljZXMNCiAgICAgICAgZGF0YSA9IHNlbGYuTUFYX0lURVJBVElPTlMg KyBOdW1lcmljLnplcm9zKHNpemUpDQogICAgICAgICMgaW5pdGlhbGl6ZSB0aGUgInRvZG8i IGFycmF5czsNCiAgICAgICAgIyB0aGV5IHdpbGwgY29udGFpbiBqdXN0IHRoZSBzcG90cyB3 aGVyZSB3ZSBzdGlsbCBuZWVkIHRvIGl0ZXJhdGUNCiAgICAgICAgY18gPSBOdW1lcmljLmFy cmF5KGMpLmFzdHlwZShOdW1lcmljLkNvbXBsZXgzMikNCiAgICAgICAgel8gPSBOdW1lcmlj LmFycmF5KHopLmFzdHlwZShOdW1lcmljLkNvbXBsZXgzMikNCiAgICAgICAgcHJvZ3Jlc3NN b25pdG9yID0gc2VsZi5zdGF0dXNDYWxsYmFjaw0KICAgICAgICB3aGlsZSAoaXRlcmF0aW9u cyA8IHNlbGYuTUFYX0lURVJBVElPTlMpIGFuZCBsZW4oaV9ubyk6DQogICAgICAgICAgICAj IGRvIHRoZSBjYWxjdWxhdGlvbnMgaW4tcGxhY2UNCiAgICAgICAgICAgIE51bWVyaWMubXVs dGlwbHkoel8sIHpfLCB6XykNCiAgICAgICAgICAgIE51bWVyaWMuYWRkKHpfLCBjXywgel8p DQogICAgICAgICAgICBvdmVyZmxvdyA9IE51bWVyaWMuZ3JlYXRlcl9lcXVhbChhYnMoel8p LCAyLjApDQogICAgICAgICAgICBub3Rfb3ZlcmZsb3cgPSBOdW1lcmljLmxvZ2ljYWxfbm90 KG92ZXJmbG93KQ0KICAgICAgICAgICAgIyBnZXQgdGhlIGluZGljZXMgd2hlcmUgb3ZlcmZs b3cgb2NjdXJlZA0KICAgICAgICAgICAgIyMjI292ZXJmbG93SW5kaWNlcyA9IE51bWVyaWMu Y29tcHJlc3Mob3ZlcmZsb3csIGlfbm8pICMgc2xvd2VyDQogICAgICAgICAgICBvdmVyZmxv d0luZGljZXMgPSBOdW1lcmljLnJlcGVhdChpX25vLCBvdmVyZmxvdykgIyBmYXN0ZXINCiAg ICAgICAgICAgICMgc2V0IHRoZSBwaXhlbCBpbmRpY2VzIHRoZXJlDQogICAgICAgICAgICBm b3IgaWR4IGluIG92ZXJmbG93SW5kaWNlczoNCiAgICAgICAgICAgICAgICBkYXRhW2lkeF0g PSBpdGVyYXRpb25zDQogICAgICAgICAgICAjIGNvbXB1dGUgdGhlIG5ldyBhcnJheSBvZiBu b24tb3ZlcmZsb3cgaW5kaWNlcw0KICAgICAgICAgICAgaV9ubyA9IE51bWVyaWMucmVwZWF0 KGlfbm8sIG5vdF9vdmVyZmxvdykNCiAgICAgICAgICAgICMgdXBkYXRlIHRoZSB0b2RvIGFy cmF5cw0KICAgICAgICAgICAgY18gPSBOdW1lcmljLnJlcGVhdChjXywgbm90X292ZXJmbG93 KQ0KICAgICAgICAgICAgel8gPSBOdW1lcmljLnJlcGVhdCh6Xywgbm90X292ZXJmbG93KQ0K ICAgICAgICAgICAgaXRlcmF0aW9ucyA9IGl0ZXJhdGlvbnMgKyAxDQogICAgICAgICAgICBw cm9ncmVzc01vbml0b3IoaXRlcmF0aW9ucywgMTAwLjAgKiBsZW4oaV9ubykgLyBzaXplKQ0K ICAgICAgICByZXR1cm4gZGF0YQ0KICAgIGRlZiBfc2V0dXAoc2VsZiwgY29vcmRpbmF0ZXMp Og0KICAgICAgICAnJydzZXR1cCBmb3IgcHJvY2Vzc2luZyBvZiBhIHNpbmdsZSB0aWxlJycn DQogICAgICAgICMgd2UgdXNlIGEgc2luZ2xlIGFycmF5IGZvciB0aGUgcmVhbCB2YWx1ZXMg Y29ycmVzcG9uZGluZyB0byB0aGUgeCBjb29yZGluYXRlcw0KICAgICAgICB3aWR0aCwgaGVp Z2h0ID0gc2VsZi50aWxlRGltZW5zaW9ucw0KICAgICAgICBkaWZmID0gY29vcmRpbmF0ZXNb MV1bMF0gLSBjb29yZGluYXRlc1swXVswXQ0KICAgICAgICB4cyA9IDBqICsgKGNvb3JkaW5h dGVzWzBdWzBdICsgTnVtZXJpYy5hcmFuZ2Uod2lkdGgpLmFzdHlwZShOdW1lcmljLkZsb2F0 MzIpICoNCiAgICAgICAgICAgICAgICAgICBkaWZmIC8gd2lkdGggKQ0KICAgICAgICAjIHdl IHVzZSBhIHNpbmdsZSBhcnJheSBmb3IgdGhlIGltYWdpbmFyeSB2YWx1ZXMgY29ycmVzcG9u ZGluZyB0byB0aGUgeSBjb29yZGluYXRlcw0KICAgICAgICBkaWZmID0gY29vcmRpbmF0ZXNb MV1bMV0gLSBjb29yZGluYXRlc1swXVsxXQ0KICAgICAgICB5cyA9IDFqICogKGNvb3JkaW5h dGVzWzBdWzFdICsgTnVtZXJpYy5hcmFuZ2UoaGVpZ2h0KS5hc3R5cGUoTnVtZXJpYy5GbG9h dDMyKSAqDQogICAgICAgICAgICAgICAgICAgZGlmZiAvIGhlaWdodCApDQogICAgICAgICMg d2UgYnVpbGQgPGM+IGluIGRpcmVjdCBjb3JyZXBvbmRlbmNlIHdpdGggdGhlIHBpeGVscyBp biB0aGUgaW1hZ2UNCiAgICAgICAgYyA9IE51bWVyaWMuYWRkLm91dGVyKHlzLCB4cykNCiAg ICAgICAgeiA9IE51bWVyaWMuemVyb3MoKGhlaWdodCwgd2lkdGgpKS5hc3R5cGUoTnVtZXJp Yy5Db21wbGV4MzIpDQogICAgICAgICMgdXNlIGZsYXR0ZW5lZCByZXByZXNlbnRhdGlvbnMg Zm9yIGVhc2llciBoYW5kbGluZyBvZiBhcnJheSBlbGVtZW50cw0KICAgICAgICBjID0gTnVt ZXJpYy5yYXZlbChjKQ0KICAgICAgICB6ID0gTnVtZXJpYy5yYXZlbCh6KQ0KICAgICAgICBy ZXR1cm4gKGMsIHopDQoNCnRyeToNCiMjICAgICAgcmFpc2UgSW1wb3J0RXJyb3INCiAgICBm cm9tIHd4UHl0aG9uLnd4IGltcG9ydCAqDQogICAgY2xhc3MgTWFuZGVsQ2FudmFzKHd4V2lu ZG93KToNCiAgICAgICAgZGVmIF9faW5pdF9fKHNlbGYsIHBhcmVudCwgaWQgPSAtMSwgd2lk dGg9NjAwLCBoZWlnaHQ9NjAwLA0KICAgICAgICAgICAgICAgICAgICAgY29vcmRpbmF0ZXM9 KCgtMi4wLC0xLjUpLCgxLjAsMS41KSksIHdlaWdodHMgPSgxNiwxLDMyKSwNCiAgICAgICAg ICAgICAgICAgICAgIGl0ZXJhdGlvbnM9MjU1LCB4ZGl2aXNvcj0wLCB5ZGl2aXNvcj0wKToN CiAgICAgICAgICAgIHd4Lnd4V2luZG93Ll9faW5pdF9fKHNlbGYsIHBhcmVudCwgaWQpDQog ICAgICAgICAgICBzZWxmLndpZHRoICA9IHdpZHRoDQogICAgICAgICAgICBzZWxmLmhlaWdo dCA9IGhlaWdodA0KICAgICAgICAgICAgc2VsZi5jb29yZGluYXRlcyA9IGNvb3JkaW5hdGVz DQogICAgICAgICAgICBzZWxmLndlaWdodHMgPSB3ZWlnaHRzDQogICAgICAgICAgICBzZWxm LnBhcmVudCA9IHBhcmVudA0KICAgICAgICAgICAgc2VsZi5ib3JkZXIgPSAoMSwxKQ0KICAg ICAgICAgICAgc2VsZi5TZXRTaXplKHd4U2l6ZSh3aWR0aCwgaGVpZ2h0KSkNCiAgICAgICAg ICAgIHNlbGYuU2V0QmFja2dyb3VuZENvbG91cih3eC53eE5hbWVkQ29sb3VyKCJibGFjayIp KQ0KICAgICAgICAgICAgc2VsZi5iaXRtYXAgPSBOb25lDQogICAgICAgICAgICBzZWxmLmNv bG91cnMgPSBOdW1lcmljLnplcm9zKCAoaXRlcmF0aW9ucyArIDEsIDMpICkNCiAgICAgICAg ICAgIGFyYW5nZU1heCA9IE51bWVyaWMuYXJhbmdlKDAsIGl0ZXJhdGlvbnMgKyAxKQ0KICAg ICAgICAgICAgc2VsZi5jb2xvdXJzWzosMF0gPSBOdW1lcmljLmNsaXAoYXJhbmdlTWF4ICog d2VpZ2h0c1swXSwgMCwgaXRlcmF0aW9ucykNCiAgICAgICAgICAgIHNlbGYuY29sb3Vyc1s6 LDFdID0gTnVtZXJpYy5jbGlwKGFyYW5nZU1heCAqIHdlaWdodHNbMV0sIDAsIGl0ZXJhdGlv bnMpDQogICAgICAgICAgICBzZWxmLmNvbG91cnNbOiwyXSA9IE51bWVyaWMuY2xpcChhcmFu Z2VNYXggKiB3ZWlnaHRzWzJdLCAwLCBpdGVyYXRpb25zKQ0KICAgICAgICAgICAgc2VsZi5p bWFnZSA9IHd4RW1wdHlJbWFnZSh3aWR0aCwgaGVpZ2h0KQ0KICAgICAgICAgICAgc2VsZi5i aXRtYXAgPSBzZWxmLmltYWdlLkNvbnZlcnRUb0JpdG1hcCgpDQogICAgICAgICAgICBzZWxm LmdlbmVyYXRvciA9IE1hbmRlbGJyb3RHZW5lcmF0b3IoIHdpZHRoPXdpZHRoLCBoZWlnaHQ9 aGVpZ2h0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBjb29yZGluYXRlcz1jb29yZGluYXRlcywNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVkcmF3Q2FsbGJhY2s9c2VsZi5kYXRhVXBk YXRlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpdGVyYXRpb25zPWl0ZXJhdGlvbnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHhkaXZpc29yPXhkaXZpc29yLCB5ZGl2aXNvcj15ZGl2 aXNvcikNCiAgICAgICAgICAgIGltcG9ydCB0aHJlYWRpbmcNCiAgICAgICAgICAgIHNlbGYu dGhyZWFkID0gdGhyZWFkaW5nLlRocmVhZCggdGFyZ2V0ID0gc2VsZi5nZW5lcmF0b3IuRG9B bGxUaWxlcyApDQogICAgICAgICAgICBzZWxmLnRocmVhZC5zdGFydCgpDQoNCiAgICAgICAg ZGVmIGRhdGFVcGRhdGUoIHNlbGYsIGRhdGEsIG1vcmU9MCApOg0KIyMgICAgICAgICAgcHJp bnQgJ2RhdGFVcGRhdGUnLCBtb3JlDQogICAgICAgICAgICBpZiBtb3JlOg0KICAgICAgICAg ICAgICAgIGRhdGEuc2hhcGUgPSAoc2VsZi5oZWlnaHQsIHNlbGYud2lkdGgpDQogICAgICAg ICAgICAgICAgIyBidWlsZCB0aGUgcGl4ZWwgdmFsdWVzDQogICAgICAgICAgICAgICAgcGl4 ZWxzID0gTnVtZXJpYy50YWtlKHNlbGYuY29sb3VycywgZGF0YSkNCiAgICAgICAgICAgICAg ICAjIGNyZWF0ZSB0aGUgaW1hZ2UgZGF0YQ0KICAgICAgICAgICAgICAgIGJpdG1hcCA9IHBp eGVscy5hc3R5cGUoTnVtZXJpYy5VbnNpZ25lZEludDgpLnRvc3RyaW5nKCkNCiAgICAgICAg ICAgICAgICAjIGNyZWF0ZSB0aGUgaW1hZ2UgaXRzZWxmDQogICAgICAgICAgICAgICAgc2Vs Zi5pbWFnZS5TZXREYXRhKGJpdG1hcCkNCiAgICAgICAgICAgICAgICBzZWxmLmJpdG1hcCA9 IHNlbGYuaW1hZ2UuQ29udmVydFRvQml0bWFwKCkNCiAgICAgICAgICAgICAgICBzZWxmLlJl ZnJlc2goKQ0KDQogICAgICAgIGRlZiBPblBhaW50KHNlbGYsIGV2ZW50KToNCiAgICAgICAg ICAgIGRjID0gd3hQYWludERDKHNlbGYpDQogICAgICAgICAgICBkYy5CZWdpbkRyYXdpbmco KQ0KICAgICAgICAgICAgaWYgc2VsZi5iaXRtYXAgIT0gMToNCiAgICAgICAgICAgICAgICBk Yy5EcmF3Qml0bWFwKHNlbGYuYml0bWFwLCAwLCAwLCBmYWxzZSkNCiAgICAgICAgICAgIGRj LkVuZERyYXdpbmcoKQ0KICAgIGNsYXNzIE15RnJhbWUod3hGcmFtZSk6DQogICAgICAgIGRl ZiBfX2luaXRfXyhzZWxmLCBwYXJlbnQsIElELCB0aXRsZSk6DQogICAgICAgICAgICB3eEZy YW1lLl9faW5pdF9fKHNlbGYsIHBhcmVudCwgSUQsIHRpdGxlKQ0KICAgICAgICAgICAgc2Vs Zi5DcmVhdGVTdGF0dXNCYXIoKQ0KIyMgICAgICAgICAgc2VsZi5wcm9ncmVzcygwLCAxMDAp DQogICAgICAgICAgICBzZWxmLkNlbnRyZSh3eEJPVEgpDQogICAgICAgICAgICBtZGIgPSBN YW5kZWxDYW52YXMoc2VsZiwgd2lkdGg9MjAwLCBoZWlnaHQ9MjAwLCBpdGVyYXRpb25zPTI1 NSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjLCB4ZGl2aXNvcj01LCB5ZGl2 aXNvcj0yMCkNCg0KICAgICAgICAgICAgc2VsZi5TZXRBdXRvTGF5b3V0KHRydWUpDQogICAg ICAgICAgICBzZWxmLkxheW91dCgpDQogICAgICAgICAgICBzZWxmLkZpdCgpDQogICAgICAg ICAgICBzeiA9IHNlbGYuR2V0Q2xpZW50U2l6ZSgpDQogICAgICAgICAgICBzZWxmLlNldENs aWVudFNpemUod3hTaXplKHN6LndpZHRoLTcsIHN6LmhlaWdodC0xNCkpDQoNCiMjICAgICAg ICAgIGRlZiBwcm9ncmVzcyhzZWxmLCBkb25lLCBwZXJjZW50KToNCiMjICAgICAgICAgICAg ICBzZWxmLlNldFN0YXR1c1RleHQoIiVkLyVkLCAlMi4yZiIgJSAoZG9uZSwgTUFYX0lURVJB VElPTlMsIHBlcmNlbnQpICsgDQojIyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICIlIG9mIHBpeGVscyBsZWZ0IikNCg0KICAgIGNsYXNzIE15QXBwKHd4QXBwKToNCiAgICAg ICAgZGVmIE9uSW5pdChzZWxmKToNCiAgICAgICAgICAgIGZyYW1lID0gTXlGcmFtZShOVUxM LCAtMSwgIk1hbmRlbGJyb3QiKQ0KICAgICAgICAgICAgZnJhbWUuU2hvdyh0cnVlKQ0KICAg ICAgICAgICAgc2VsZi5TZXRUb3BXaW5kb3coZnJhbWUpDQogICAgICAgICAgICByZXR1cm4g dHJ1ZQ0KDQogICAgYXBwID0gTXlBcHAoMCkNCiAgICBhcHAuTWFpbkxvb3AoKQ0KZXhjZXB0 IEltcG9ydEVycm9yOg0KICAgIGRlZiB0ZXN0KCk6DQogICAgICAgIG0gPSBNYW5kZWxicm90 R2VuZXJhdG9yKCkNCiAgICAgICAgd2hpbGUgbS5Eb1RpbGUoKToNCiAgICAgICAgICAgIHBy aW50ICcuJw0KICAgIHRlc3QoKQ0K --------------BFD45A5A87DC8AE4E557A208-- From humbert@hagen.de Wed Jul 11 17:43:28 2001 From: humbert@hagen.de (L. Humbert) Date: Wed, 11 Jul 2001 18:43:28 +0200 Subject: [Edu-sig] The Pedagogical Patterns Project Message-ID: <3B4C8230.86D091BC@hagen.de> Hi, I just found http://www-lifia.info.unlp.edu.ar/ppp/index.html " The Pedagogical Patterns Project Successes in Teaching Object Technology (PROTO-PATTERNS) The process of training, retraining, and, most of all, educating people in object technology is an ongoing challenge which has many unanswered questions. While many good pedagogical ideas are presented at OO conferences and published in proceedings and journals each year, very little has been done to collate the effective practices of many OO educators into one publication. The purpose of the pedagogical patterns project is do just that, to create a publication which is similar to what Susan Lilly (in 1/96 Object Magazine) refers to as "reusable pedagogical design patterns". According to Lilly, a pedagogical pattern should be repeatable and easy to adapt. Each pattern should be described in a way that allows it to be easily "instantiated" for different lessons by different instructors. However, patterns do not need to be new or original. Lilly compares this to the Gamma et al. "Design Patterns" book, as follows: "The largest contribution of the 'Gang of Four' book is the documentation of patterns that have been proven to work, not the invention of the solutions. What makes patterns useful is their ability to communicate proven solutions to common problems." ... " Perhaps here are some keep people to take a closer look at this pages - I have'nt much time to look at it deep, but it looks very interesting to me. Ludger From wwwjessie@21cn.com Thu Jul 12 11:01:49 2001 From: wwwjessie@21cn.com (wwwjessie@21cn.com) Date: Thu, 12 Jul 2001 18:01:49 +0800 Subject: [Edu-sig] =?gb2312?B?xvPStcnPzfijrNK7sr21vc67KFlvdXIgb25saW5lIGNvbXBhbnkp?= Message-ID: <34ea801c10ab9$aaca59a0$9300a8c0@ifood1gongxing> This is a multi-part message in MIME format. ------=_NextPart_000_34EA9_01C10AFC.B8ED99A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 1/C+tLXEu+HUsaOsxPq6w6Oh0rzKs8a31tC5+s34t/7O8dDFz6K5qcT6ss6/vKO6ICANCg0K07XT 0NfUvLq1xM34yc+5q8u+o6zVucq+uavLvrL6xre6zbf+zvGjrMzhuN/G89K1vrrV+cGmLMT609DB vdbW0aHU8aO6DQoNCjEvIM341b62qNbGIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9v dXJzZXJ2aWNlcy93ZWIuYXNwPiAgOg0K19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G 89K10OjSqqOsvajBotfUvLq1xM34yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+i t6KyvCzN+MnPsvrGt9W5yr6jrL/Nu6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYDQrPtbnc wO0szfjJz8LbzLMszfjJz7vh0unW0NDELM34yc/V0Ma4LM22xrHPtc2zLNfKwc/PwtTY1tDQxCzO yr7ttfey6Swg1dCx6rLJubrPtc2zLLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0Cmh raGtDQoNCs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/x+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNv bSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhz/rK27K/ yfLQob3jDQoNCjIvINK8zfjNqCA8aHR0cDovL29uZXQuaWZvb2QxLmNvbS8+DQot19TW+sq9vajN +KOsstnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOs v8nL5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU +cvNtv68trn6vMrT8sP7KA0KyOdodHRwOi8veW91cm5hbWUuaWZvb2QxLmNvbSmjrNPr0rzKs8a3 1tC5+s34KNKzw+bkr8DAwb/UwtPiMjAwzfK0zim99MPcway906OszOG438LyvNK6zbnLv823w87K wb+jrLaoxtrK1bW90rzKsw0KxrfW0Ln6zfjM4bmptcS/zbun0OjH87rNssm5utDFz6Khow0KDQoN Cg0KN9TCMzDI1cewyerH67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5 y83M9cLrueO45rKiw+K30dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6IN Cs/rwcu94rj8tuA/IKGhx+vBqs+1o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlm b29kMS5jb20+DQqhobXnu7CjujA3NTUtMzc4NjMwOaGhoaHP+srbsr/J8tChveMNCrvyILfDzsrO 0sPHtcTN+NKzIDxodHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNl cnZpY2UuYXNwPg0KOnd3dy5pZm9vZDEuY29tDQoNCrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3 u/K3orXn19PTyrz+o7ogc2FsZXNAaWZvb2QxLmNvbSA8bWFpbHRvOnNhbGVzQGlmb29kMS5jb20+ IKOpDQoNCqH1ILG+uavLvrbUzfjVvrao1sa40NDLyKShoaGhICAgICAgICAgICAgICAgICAgICAg ofUgsb65q8u+ttTSvM34zai3/s7xuNDQy8ikDQoNCrmry77D+7PGo7pfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9fX19fX19fX19fX19fX19fXw0K X19fX18gDQoNCrXnu7Cjul9fX19fX19fX19fX19fX19fX19fX7Sr1eajul9fX19fX19fX19fX19f X19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX18NCl9fX19fXyANCg0K ------=_NextPart_000_34EA9_01C10AFC.B8ED99A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5VbnRpdGxlZCBEb2N1bWVudDwvVElUTEU+IDxNRVRBIEhU VFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx MiI+IA0KPC9IRUFEPg0KDQo8Qk9EWSBCR0NPTE9SPSIjRkZGRkZGIiBURVhUPSIjMDAwMDAwIj4N CjxUQUJMRSBXSURUSD0iOTglIiBCT1JERVI9IjAiIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElO Rz0iMCI+PFRSPjxURD48UCBDTEFTUz1Nc29Ob3JtYWwgU1RZTEU9J21hcmdpbi1yaWdodDotMTcu ODVwdDtsaW5lLWhlaWdodDoxNTAlJz48Rk9OVCBTSVpFPSIyIj7X8L60tcS74dSxo6zE+rrDo6HS vMqzxrfW0Ln6zfi3/s7x0MXPormpxPqyzr+8o7ombmJzcDs8L0ZPTlQ+IA0KPC9QPjxQIENMQVNT PU1zb05vcm1hbCBTVFlMRT0nbWFyZ2luLXJpZ2h0Oi0xNy44NXB0O2xpbmUtaGVpZ2h0OjE1MCUn PjxGT05UIFNJWkU9IjIiPtO109DX1Ly6tcTN+MnPuavLvqOs1bnKvrmry76y+sa3us23/s7xo6zM 4bjfxvPStb661fnBpizE+tPQwb3W1tGh1PGjujxCUj48QlI+MS8gDQo8QQ0KSFJFRj0iaHR0cDov L3d3dy5pZm9vZDEuY29tL2Fib3V0dXMvb3Vyc2VydmljZXMvd2ViLmFzcCI+zfjVvrao1sY8L0E+ IDog19S8us6su6S4/NDCo6y53MDtx7DMqLrzzKijrLj5vt3G89K10OjSqqOsvajBotfUvLq1xM34 yc+5q8u+o6zK/b7dv+LEo7/pyM7E+tGh1PGjusnMx+nQxc+it6KyvCzN+MnPsvrGt9W5yr6jrL/N u6e3/s7x1tDQxCzN+MnPubrO78+1zbMsv827p7nYz7W53MDtLM34yc/C28yzLM34yc+74dLp1tDQ xCzN+MnP1dDGuCzNtsaxz7XNsyzXysHPz8LU2NbQ0MQszsq+7bX3suksIA0K1dCx6rLJubrPtc2z LLfDzsrV382zvMa31s72LCDBxMzsytIovbvB96GizLjF0CmhraGtPC9GT05UPjwvUD48UCBDTEFT Uz1Nc29Ob3JtYWwgU1RZTEU9J2xpbmUtaGVpZ2h0OjIwLjBwdCc+PEI+PEZPTlQgQ09MT1I9IiNG RjAwMDAiPs/rwcu94sr9vt2/4sSjv+nR3cq+1tDQxKO/PC9GT05UPjwvQj48Rk9OVCBTSVpFPSIy Ij7H68Gqz7WjujxBIEhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEu Y29tPC9BPiANCqGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr/J8tChveM8L0ZPTlQ+PC9QPjxQ IENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0Jz48L1A+PFAgQ0xBU1M9 TXNvTm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPjIvIA0K PEEgSFJFRj0iaHR0cDovL29uZXQuaWZvb2QxLmNvbS8iPtK8zfjNqDwvQT4t19TW+sq9vajN+KOs stnX97zytaWjrLy0vai8tNPDo7q/ydW5yr4zMNXFu/K4/Lbg1dXGrKOs19TW+sq9zqy7pKOsv8nL 5sqxuPzQws28xqy6zc7E19bE2sjdo6zU2s/ft6KyvLL6xrfQxc+ioaK5q8u+tq/MrLXIo6zU+cvN tv68trn6vMrT8sP7KMjnaHR0cDovL3lvdXJuYW1lLmlmb29kMS5jb20po6zT69K8yrPGt9bQufrN +CjSs8Pm5K/AwMG/1MLT4jIwMM3ytM4pvfTD3MGsvdOjrMzhuN/C8rzSus25y7/Nt8POysG/o6y2 qMbaytW1vdK8yrPGt9bQufrN+Mzhuam1xL/Nu6fQ6Mfzus2yybm60MXPoqGjPEJSPjwvRk9OVD48 L1A+PFAgQ0xBU1M9TXNvTm9ybWFsIFNUWUxFPSdtYXJnaW4tcmlnaHQ6LTE3Ljg1cHQ7bGluZS1o ZWlnaHQ6MTUwJSc+PEZPTlQgU0laRT0iMiI+PEJSPjwvRk9OVD4gDQo8Qj48Rk9OVCBDT0xPUj0i I0ZGMDAwMCI+NzwvRk9OVD48L0I+PEZPTlQgQ09MT1I9IiNGRjAwMDAiPjxCPtTCMzDI1cewyerH 67KiuLa/7sq508PSvM34zaijrMzYsfDTxbvdvNszODAw1KovxOqjrNT5y83M9cLrueO45rKiw+K3 0dTayrPGt9eo0rXU09a+v6+1x7mpo6zH86OstPrA7aOsus/X99DFz6I8L0I+PEJSPjwvRk9OVD4g DQo8Rk9OVCBTSVpFPSIyIj7P68HLveK4/LbgPyChocfrwarPtaO6PEEgSFJFRj0ibWFpbHRvOnNh bGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L0E+IA0KoaG157uwo7owNzU1LTM3ODYz MDmhoaGhz/rK27K/yfLQob3jPEJSPjwvRk9OVD48Rk9OVCBTSVpFPSIyIj678jxBDQpIUkVGPSJo dHRwOi8vd3d3Lmlmb29kMS5jb20vYWJvdXR1cy9vdXJzZXJ2aWNlcy9jcHNlcnZpY2UuYXNwIj63 w87KztLDx7XEzfjSszwvQT46d3d3Lmlmb29kMS5jb208L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05v cm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6MjAuMHB0JyBBTElHTj0iTEVGVCI+PC9QPjxQIENMQVNT PU1zb05vcm1hbCBBTElHTj1MRUZUIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJ WkU9IjIiPjxCPrvY1rSjqMfrtKvV5qO6MDc1NS0zMjM5MDQ3u/K3orXn19PTyrz+o7o8L0I+PEEN CkhSRUY9Im1haWx0bzpzYWxlc0BpZm9vZDEuY29tIj5zYWxlc0BpZm9vZDEuY29tIDwvQT48Qj6j qTwvQj48L0ZPTlQ+PC9QPjxQPjxGT05UIFNJWkU9IjIiPqH1IA0Ksb65q8u+ttTN+NW+tqjWxrjQ 0MvIpKGhoaEmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IKH1ILG+uavLvrbU0rzN+M2ot/7O8bjQ0MvIpDwvRk9OVD48L1A+PFAgQ0xBU1M9TXNv Tm9ybWFsIFNUWUxFPSdsaW5lLWhlaWdodDoyMC4wcHQnPjxGT05UIFNJWkU9IjIiPrmry77D+7PG o7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1/Bqs+1yMujul9f X19fX19fX19fX19fX19fX19fX19fIA0KPEJSPiA8QlI+ILXnu7Cjul9fX19fX19fX19fX19fX19f X19fX7Sr1eajul9fX19fX19fX19fX19fX19fX19fX19FLW1haWyjul9fX19fX19fX19fX19fX19f X19fX18gDQo8L0ZPTlQ+PC9QPjxQIENMQVNTPU1zb05vcm1hbCBTVFlMRT0nbGluZS1oZWlnaHQ6 MjAuMHB0Jz48L1A+PC9URD48L1RSPjwvVEFCTEU+IA0KPC9CT0RZPg0KPC9IVE1MPg0K ------=_NextPart_000_34EA9_01C10AFC.B8ED99A0-- From humbert@hagen.de Thu Jul 12 20:30:27 2001 From: humbert@hagen.de (L. Humbert) Date: Thu, 12 Jul 2001 21:30:27 +0200 Subject: [Edu-sig] [Fwd: typo.py - Warn of typographical errors in Python scripts] Message-ID: <3B4DFAD3.BD4E3201@hagen.de> This is a multi-part message in MIME format. --------------858CE74DE3707D29EFC46ED1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, some of you, however, may get this message twice. But I think, it is worth enough. Ludger --------------858CE74DE3707D29EFC46ED1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: news.t-online.com!newsmm00.sul.t-online.com!newsfeed01.sul.t-online.de!t-online.de!lnewspeer00.lnd.ops.eu.uu.net!emea.uu.net!zur.uu.net!ash.uu.net!news.baymountain.net!not-for-mail From: "Alan Klietz" Newsgroups: comp.lang.python.announce Subject: typo.py - Warn of typographical errors in Python scripts Date: Mon, 9 Jul 2001 11:55:06 -0500 Organization: Algin Technology Approved: clpa-moderators@python.org Message-ID: NNTP-Posting-Host: mail.python.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: news.baymountain.net 994764060 9562 63.102.49.29 (10 Jul 2001 11:21:00 GMT) X-Complaints-To: abuse@baymountain.net NNTP-Posting-Date: 10 Jul 2001 11:21:00 GMT To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Errors-To: clpa-moderators-admin@python.org X-BeenThere: clpa-moderators@python.org X-Mailman-Version: 2.0.5 (101270) Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , Errors-To: clpa-moderators-admin@python.org X-BeenThere: clpa-moderators@python.org Xref: news.t-online.com comp.lang.python.announce:1314 One of the most common annoyances with using Python is that it does not report typographical errors in variable names at compile time. For example, def compute_area(width, height): area = width * hieght # oops Another example is a typo in an attribute for a class, class Square: def __init__(self, width, height): self.width = width self.hieght = height # oops def compute_area(self): return self.width * self.height typo.py will catch these errors and report them: hieght might be used before set at line 2 self.height might be undefined at line 7 You can download typo.py from http://utools.com/typo.htm Alan Klietz Algin Technology alank@algintech.NOSPAM.com --------------858CE74DE3707D29EFC46ED1-- From wwwjessie@21cn.com Mon Jul 16 10:47:32 2001 From: wwwjessie@21cn.com (wwwjessie@21cn.com) Date: Mon, 16 Jul 2001 17:47:32 +0800 Subject: [Edu-sig] =?gb2312?B?tPPBrC0yMDAxxOq5+rzKwszJq8qzxrfT68jLwOC9ob+1sqnAwLvhKA==?= =?gb2312?B?QWdybyBBbm51YWwgTWVldGluZyBDaGluYSAyMDAxKQ0=?= Message-ID: <2d91401c10ddc$55732420$9300a8c0@ifood1gongxing> This is a multi-part message in MIME format. ------=_NextPart_000_2D915_01C10E1F.63966420 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MjAwMcTq1tC5+rn6vMrFqdK1v8a8vMTqu+ENCrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8 sNGnyvXM1sLbu+ENCg0KCQ0K1bnG2qO6IAmhoTIwMDHE6jnUwjTI1S03yNUJDQq12LXjo7ogCaGh tPPBrNDHuqO74dW51tDQxAkNCtb3sOyjuiAJoaHW0LuqyMvD8bmyus25+sWp0rWyvw0KoaHW0Ln6 v8bRp7y8yvXQrbvhDQqhobTzwazK0MjLw/HV/riuDQoJDQqz0LDso7ogCaGh1tC5+sLMyavKs8a3 t6LVudbQ0MQNCqGh1tC5+sWp0ae74Q0KoaHW0Ln6wszJq8qzxrfQrbvhDQqhobTzwazK0MWp0rW+ 1g0KoaG088Gs0Me6o7vh1bnW0NDEDQoJDQrN+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IGh0 dHA6Ly93d3cuaWZvb2QxLmNvbQ0KPGh0dHA6Ly93d3cuaWZvb2QxLmNvbS9pbmRleC5hc3A/ZnI9 ZWR1LXNpZ0BweXRob24ub3JnPiAJDQogCQ0Kofogzai5/dK8yrPGt9bQufrN+LGow/uyztW5o7q+ xdXb08W73SixyMjnz9bT0MO/uPYgM00gWCAzTSC1xLHq17zVuc671K2821JNQjQ1MDCjrM2ouf3O 0sPH1rvQ6Li2Uk1CNDA1MCmjrA0KsajD+73Y1rnI1cbaMjAwMcTqN9TCMjDI1SA8aHR0cDovL2dy ZWVuMjAwMS5pZm9vZDEuY29tL2Zyb20xLmFzcD4gDQqh+iC7ttOtIMPit9HXorLhIDxodHRwOi8v d3d3Lmlmb29kMS5jb20vc2lnbnVwL3NldmFncmVlbS5hc3A+ILPJzqq5q8u+u+HUsaGjDQo31MIy MMjVx7DXorLho6zE+r2r1No31MIyNcjVx7DNqLn9tefX09PKvP63vcq9w+K30bvxtcMzMMz1ssm5 utDFz6Khow0KyOe5+8T6srvP68rVtb3O0sPHtcTTyrz+o6zH6yDBqs+1ztLDxyA8bWFpbHRvOnVu c3Vic2NyaWJlQGlmb29kMS5jb20+IKOsztLDx9LUuvO9q7K71Nm3otPKvP64+MT6oaMNCrLp0a+j uiBzYWxlc0BpZm9vZDEuY29tIDxtYWlsdG86c2FsZXNAaWZvb2QxLmNvbT4gIKGhoaG157uwo7ow NzU1LTM3ODYzMDmhoc/6ytuyvw0KyfLQob3jILbFz8jJ+g0KDQoNCiANCg0Ku9gg1rQgo6jH67Sr 1eajujA3NTUtMzIzOTA0N7vyILeitefX09PKvP6juiBzYWxlc0BpZm9vZDEuY29tIDxtYWlsdG86 c2FsZXNAaWZvb2QxLmNvbT4NCqOpCQ0KofUgsb65q8u+09DS4s2ouf3SvMqzxrfW0Ln6zfiyztW5 IKGhoaEgofUgsb65q8u+xOK9+NK7sr3By73iuMOyqcDAu+GjrMfr0+vO0sPHwarPtQ0KDQq5q8u+ w/uzxqO6X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCsGqz7XIy6O6X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ktee7sKO6X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KtKvV5qO6X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRS1tYWlso7pfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoJDQogCQ0KIAkNCiAJDQogCQ0KIAkNCg== ------=_NextPart_000_2D915_01C10E1F.63966420 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+IDxtZXRhIGh0 dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMx MiI+IA0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCnRkIHsgIGxpbmUtaGVpZ2h0OiAy NHB4fQ0KLS0+DQo8L3N0eWxlPiANCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIg dGV4dD0iIzAwMDAwMCI+DQo8ZGl2IGFsaWduPSJDRU5URVIiPjx0YWJsZSB3aWR0aD0iNzUlIiBi b3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+PHRyPjx0ZCBhbGlnbj0i Q0VOVEVSIj48YSBocmVmPSJodHRwOy8vZ3JlZW4yMDAxLmlmb29kMS5jb20iPjxiPjIwMDHE6tbQ ufq5+rzKxanStb/GvLzE6rvhPGJyPrn6vMrCzMmryrPGt9PryMvA4L2hv7WyqcDAu+G8sNGnyvXM 1sLbu+E8L2I+PC9hPjxicj48YnI+PC90ZD48L3RyPjx0cj48dGQgYWxpZ249IkNFTlRFUiI+PHRh YmxlIHdpZHRoPSI3NSUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw Ij48dHI+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSIzOSUiIGFsaWduPSJSSUdIVCI+PGI+PGZvbnQg c2l6ZT0iMiI+1bnG2qO6IA0KPC9mb250PjwvYj48L3RkPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0i NjElIj48Zm9udCBzaXplPSIyIj6hoTIwMDHE6jnUwjTI1S03yNU8L2ZvbnQ+PC90ZD48L3RyPjx0 cj48dGQgaGVpZ2h0PSIxMiIgd2lkdGg9IjM5JSIgYWxpZ249IlJJR0hUIj48Yj48Zm9udCBzaXpl PSIyIj612LXjo7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUi Pjxmb250IHNpemU9IjIiPqGhtPPBrNDHuqO74dW51tDQxDwvZm9udD48L3RkPjwvdHI+PHRyPjx0 ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0iUklHSFQiIHZhbGlnbj0iVE9QIj48Yj48 Zm9udCBzaXplPSIyIj7W97Dso7ogDQo8L2ZvbnQ+PC9iPjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdp ZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250Pjxmb250IHNpemU9IjIiPtbQu6rIy8Px ubK6zbn6xanStbK/PGJyPqGh1tC5+r/G0ae8vMr10K274Txicj6hobTzwazK0MjLw/HV/riuPGJy PjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiB3aWR0aD0iMzklIiBhbGlnbj0i UklHSFQiIHZhbGlnbj0iVE9QIj48Yj48Zm9udCBzaXplPSIyIj6z0LDso7ogDQo8L2ZvbnQ+PC9i PjwvdGQ+PHRkIGhlaWdodD0iMTIiIHdpZHRoPSI2MSUiPjxmb250IHNpemU9IjIiPqGhPC9mb250 Pjxmb250IHNpemU9IjIiPtbQufrCzMmryrPGt7ei1bnW0NDEPGJyPqGh1tC5+sWp0ae74Txicj6h odbQufrCzMmryrPGt9Ctu+E8YnI+oaG088GsytDFqdK1vtY8YnI+oaG088Gs0Me6o7vh1bnW0NDE PGJyPjwvZm9udD48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48 Zm9udCBzaXplPSIyIj7N+MLnt/7O8czhuanJzKO60rzKs8a31tC5+s34IA0KPGEgaHJlZj0iaHR0 cDovL3d3dy5pZm9vZDEuY29tL2luZGV4LmFzcD9mcj1lZHUtc2lnQHB5dGhvbi5vcmciPmh0dHA6 Ly93d3cuaWZvb2QxLmNvbTwvYT48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgY29sc3Bhbj0iMiIg YWxpZ249IkNFTlRFUiI+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQgY29sc3Bhbj0iMiIgYWxpZ249 IkxFRlQiPjxwPjxmb250IHNpemU9IjIiPqH6IA0Kzai5/dK8yrPGt9bQufrN+LGow/uyztW5o7o8 Yj48Zm9udCBzaXplPSIzIiBjb2xvcj0iI0ZGMDAwMCI+vsXV29PFu908L2ZvbnQ+PC9iPiixyMjn z9bT0MO/uPYgM00gWCAzTSANCrXEserXvNW5zrvUrbzbUk1CNDUwMKOszai5/c7Sw8fWu9DouLZS TUI0MDUwKaOsIDxhIGhyZWY9Imh0dHA6Ly9ncmVlbjIwMDEuaWZvb2QxLmNvbS9mcm9tMS5hc3Ai PjxiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjRkYwMDAwIj6xqMP7vdjWucjVxtoyMDAxxOo31MIy MMjVPC9mb250PjwvYj48L2E+PGJyPqH6IA0Ku7bTrTxhIGhyZWY9Imh0dHA6Ly93d3cuaWZvb2Qx LmNvbS9zaWdudXAvc2V2YWdyZWVtLmFzcCI+w+K30deisuE8L2E+s8nOqrmry7674dSxoaMgPGZv bnQgY29sb3I9IiNGRjAwMDAiPjxiPjxmb250IHNpemU9IjMiPjfUwjIwyNXHsNeisuGjrMT6vavU 2jfUwjI1yNXHsM2ouf2159fT08q8/re9yr3D4rfRu/G1wzMwzPWyybm60MXPoqGjPC9mb250Pjwv Yj48L2ZvbnQ+PGJyPsjnufvE+rK7z+vK1bW9ztLDx7XE08q8/qOsx+s8YSBocmVmPSJtYWlsdG86 dW5zdWJzY3JpYmVAaWZvb2QxLmNvbSI+warPtc7Sw8c8L2E+o6zO0sPH0tS6872rsrvU2bei08q8 /rj4xPqhozxicj6y6dGvo7o8YSBocmVmPSJtYWlsdG86c2FsZXNAaWZvb2QxLmNvbSI+c2FsZXNA aWZvb2QxLmNvbTwvYT4gDQqhoaGhtee7sKO6MDc1NS0zNzg2MzA5oaHP+srbsr8gyfLQob3jILbF z8jJ+jxicj48L2ZvbnQ+PC9wPjxwPiZuYnNwOzwvcD48L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9 IjMwIiBjb2xzcGFuPSIyIiBhbGlnbj0iQ0VOVEVSIj48Zm9udCBzaXplPSIyIj48Yj672CANCta0 IKOox+u0q9Xmo7owNzU1LTMyMzkwNDe78iC3orXn19PTyrz+o7ogPGEgaHJlZj0ibWFpbHRvOnNh bGVzQGlmb29kMS5jb20iPnNhbGVzQGlmb29kMS5jb208L2E+IA0Ko6k8L2I+PC9mb250PjwvdGQ+ PC90cj48dHI+PHRkIGhlaWdodD0iMTIiIGNvbHNwYW49IjIiPjxmb250IHNpemU9IjIiPqH1ILG+ uavLvtPQ0uLNqLn90rzKs8a31tC5+s34ss7VuSANCqGhoaEgofUgsb65q8u+xOK9+NK7sr3By73i uMOyqcDAu+GjrMfr0+vO0sPHwarPtTxicj48YnI+uavLvsP7s8ajul9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPsGqz7XIy6O6X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+tee7sKO6X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj60q9Xmo7pfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPkUtbWFpbKO6X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj48L2ZvbnQ+PC90ZD48L3RyPjx0cj48dGQgaGVpZ2h0PSIxMiIgY29sc3Bhbj0i MiIgYWxpZ249IkxFRlQiPiZuYnNwOzwvdGQ+PC90cj48dHI+PHRkIGhlaWdodD0iMTIiIGNvbHNw YW49IjIiIGFsaWduPSJMRUZUIj4mbmJzcDs8L3RkPjwvdHI+PHRyPjx0ZCBoZWlnaHQ9IjEyIiBj b2xzcGFuPSIyIiBhbGlnbj0iTEVGVCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3Ry Pjx0cj48dGQ+Jm5ic3A7PC90ZD48L3RyPjx0cj48dGQ+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+ PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= ------=_NextPart_000_2D915_01C10E1F.63966420-- From pdx4d@teleport.com Mon Jul 16 19:15:02 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 16 Jul 2001 11:15:02 -0700 Subject: [Edu-sig] Pythonic chatter (more cryptology stuff) In-Reply-To: <3B4DFAD3.BD4E3201@hagen.de> Message-ID: <4.2.0.58.20010716091515.00bdb960@pop3.norton.antivirus> Finally discovered after all this time the __invert__ overrides the tilde (~). I've decided to use that with permutations, which in one form are for letter substitutions (hence the encrypt method): >>> from ciphers import P # P is a permutation class >>> P.domain # default class variable 1-10 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> import string >>> P.domain = list(string.letters + string.whitespace) >>> p = P() # P() w/o arguments gives random permutation >>> c=p.encrypt("Simple 'clubhouse code' substitution") >>> c "B\tFzutj'AunmNUnltjAUft'jlnmlk\tknk\tUv" >>> print c # what's a bit odd is to have TAB in the mix B Fzutj'AunmNUnltjAUft'jlnmlk knk Uv >>> invp = ~p # using the __invert__ operator >>> invp.encrypt("B\tFzutj'AunmNUnltjAUft'jlnmlk\tknk\tUv") "Simple 'clubhouse code' substitution" Encrypting ciphertext with the inverse permutation is the same as decrypting. That explains the class method: def decrypt(self,ciphertext): other = ~self return other.encrypt(ciphertext) >>> newp.decrypt("B\tFzutj'AunmNUnltjAUft'jlnmlk\tknk\tUv") "Simple 'clubhouse code' substitution" How is a permutation expressed, i.e. what's the __repr__ mechanism? I've chosen the disjoint cycles method, e.g. the above permutation would show up as: >>> p Permutation: [('z', 'g', 'V', 'x', 'L', 'D', ' ', 'j', 'M', 'r', 'J', 'd', 'f', '\n', '\x0c', '\r', 'I', 'i', '\t', 'e', 't', 'k', 'T', 'b', 'm', 'F', 'O', 'R', 'C', 's', 'l', 'u', 'n', 'v', '\x0b', 'Y', 'c', 'A', 'K', 'p'), ('y', 'o', 'U', 'S', 'B', 'W', 'H', 'P', 'a', 'Q', 'h', 'N', 'w', 'E', 'X', 'G')] This means 'z' becomes 'g', 'g' becomes 'V' and so on, up to where 'p' wraps to the start of the tuple, and becomes 'z'. You can see the 'z' in the 4th position, in B\tFzutj, realizing the \t is one whitespace character: TAB. Notice that the single quote character doesn't appear in the above and therefore maps to itself -- in this case because I left punctuation characters out of the domain altogther (in other cases, it might have been a random self-association). A more complete domain might have been list(string.printable) -- or maybe: >>> from string import * >>> P.domain = list(letters + punctuation + " ") Changing the class variable alters the domain for new permutations, but the __init__ method internally promotes the class-level domain to an instance level, so already- defined objects don't forget the domain upon which they were generated: >>> newp = P() # using new class default for domain >>> len(newp.domain) 85 >>> len(p.domain) 58 You can see the promotion in __init__: if domain != None: self.domain = domain else: self.domain = P.domain # initialize instance variable Another override in the P class template might be less advised than __invert__: I decided to make ^ a synonym for **, since so many languages express exponentiation with the caret (in Python, it's default meaning is XOR). Given __pow__ was already defined, changing the meaning of ^ is accomplished in a single line: __xor__ = __pow__ # use p^3 instead of p**3 if you like Raising a permutation to an nth power is like applying it n times, i.e. if 'v' becomes 'z' and 'z' becomes 'r', then in a 2nd powering, 'v' goes straight to 'r'. This is easier to track with a smaller domain: >>> P.domain = range(1,11) >>> p1 = P() >>> p1 Permutation: [(10, 7, 3, 6, 1, 4, 9, 5, 8)] >>> p1**2 Permutation: [(10, 3, 1, 9, 8, 7, 6, 4, 5)] >>> p1**3 Permutation: [(10, 6, 9), (8, 3, 4), (7, 1, 5)] There's this not-so-hard-to-prove theorem that any permutation can be raised to a power that's the lowest common multiple of the lengths of all the cycles, which will give the identity permutation as the result. This power is called the "order of P" and it's easy enough to implement. def ord(self): """ returns the exponent n of p such that p**n = [] (identity element) """ return reduce(lcm, [1]+map(len, self.mkcycles())) self.mkcycles is the utility for converting an internal substitution dictionary to cyclic format, i.e. is what's used in __repr__ as well: def __repr__(self): return "Permutation: " + str(self.mkcycles()) lcm, on the other hand, lives outside the class (but is still accessible in the module, even when we just import P): def gcd(a,b): """Return greatest common divisor using Euclid's Algorithm.""" while b: a, b = b, a % b return a def lcm(a,b): """ Return lowest common multiple.""" return (a*b)/gcd(a,b) Euclid's algorithm, and this simple implementation (I think originally by Guido, right?) is something I've been trying to reinject into USAer K-12 math classrooms. It's one of the oldest algorithms on the books, and involves geometric reasoning -- the kind of thing Arthur grooves on. And yet you'll find it's hardly ever mentioned in K-12 math (more evidence of its quasi-total corruption). Why make 'em wait to college for this -- by then we've lost over 50% to non- math-related majors, i.e. by then it's too late. So what's the order of our permutation? >>> p1.ord() 9 >>> p1^9 # same as p1**9 Permutation: [] The identity permutation, used for encryption, is pretty useless, as it just gives you your message back: >>> P.domain = list(letters + punctuation + " ") >>> p2 = P() >>> p2.ord() 13860 >>> p3 = p2**13860 # takes a few secs on a 1.2 ghz machine >>> p3.encrypt("Able was I ere I saw Elba") 'Able was I ere I saw Elba' Doh! But there's a good segue here: suppose we encrypt by using an nth power of the permutation, and then decrypt by using an (order-n) permutation? I.E.: >>> pe = p2**200 >>> pe.encrypt("Able was I ere I saw Elba") 'C>JDuMb\\u#uDrDu#u\\bMu)J>b' >>> pd = p2**(p2.ord()-200) # power "the rest of the way" >>> pd.encrypt('C>JDuMb\\u#uDrDu#u\\bMu)J>b') 'Able was I ere I saw Elba' That's getting at how RSA works. You encrypt m by raising it to the 3rd power (say), modulo N, and then you raise the "rest of the way" to get back m. Figuring out what "the rest of the way" is requires knowing the prime factors of N, of which their are only two -- needles in a haystack the size of Manhatten. Kirby More: http://www.inetarena.com/~pdx4d/ocn/crypto0.html From vmgautam@icenet.net Tue Jul 17 07:36:59 2001 From: vmgautam@icenet.net (Sanjeev Gautam) Date: Tue, 17 Jul 2001 12:06:59 +0530 Subject: [Edu-sig] Free Business Listing !! Message-ID: <200107170636.MAA04445@popsmtp1.icenet.net> New Page 1

EXIMList.Com
Attention !! Manufacturers, Exporters & Importers

You can now add your company's listing for FREE and get exposed to thousands of buyers & suppliers who visit us every month.  We have over 10500 listings in over 700 categories and sub categories.

  • Your business listing will be added to all the relevant product categories available on EXIMList.Com
  • If you do not have an e-mail account, we would forward your queries to you, free of cost, by post.
  • Coming Soon - A free online query form, which the business visitors can use to send you online business enquiries.
  • Our Virtual Market will help you to post your business directly for others to see.
  • Advertise on our directory and see your business grow.  For advertising inquiries contact us for details.

 

 

From pdx4d@teleport.com Tue Jul 17 09:43:18 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Tue, 17 Jul 2001 01:43:18 -0700 Subject: [Edu-sig] Easy fractal program In-Reply-To: <4.2.0.58.20010716091515.00bdb960@pop3.norton.antivirus> References: <3B4DFAD3.BD4E3201@hagen.de> Message-ID: <4.2.0.58.20010717005340.00cf8d40@pop3.norton.antivirus> A not so fast/efficient way to get a fractal, by a long shot, but easy enough to understand given the 'Numeracy + Computer Literacy' modules: http://www.inetarena.com/~pdx4d/ocn/fractals.html A place to start. Numeric + PIL could follow. Kirby From gritsch@iue.tuwien.ac.at Tue Jul 17 10:15:47 2001 From: gritsch@iue.tuwien.ac.at (Markus Gritsch) Date: Tue, 17 Jul 2001 11:15:47 +0200 Subject: [Edu-sig] Easy fractal program References: <3B4DFAD3.BD4E3201@hagen.de> <4.2.0.58.20010717005340.00cf8d40@pop3.norton.antivirus> Message-ID: <3B540243.172E511F@iue.tuwien.ac.at> Kirby Urner wrote: > > A not so fast/efficient way to get a fractal, by a > long shot, but easy enough to understand given the > 'Numeracy + Computer Literacy' modules: > > http://www.inetarena.com/~pdx4d/ocn/fractals.html Where can one find the povray and coords modules? Markus From pdx4d@teleport.com Tue Jul 17 16:25:36 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Tue, 17 Jul 2001 08:25:36 -0700 Subject: [Edu-sig] Easy fractal program In-Reply-To: <3B540243.172E511F@iue.tuwien.ac.at> References: <3B4DFAD3.BD4E3201@hagen.de> <4.2.0.58.20010717005340.00cf8d40@pop3.norton.antivirus> Message-ID: <4.2.0.58.20010717082304.00a43f10@pop3.norton.antivirus> > > > http://www.inetarena.com/~pdx4d/ocn/fractals.html > >Where can one find the povray and coords modules? > >Markus Good question -- I need to add a link to fractals.html. They're in a zip (python101.zip) with some other py files via http://www.inetarena.com/~pdx4d/ocn/numeracy0.html (scroll to bottom). These numeracy pages are written around those files. Kirby From dyoo@hkn.eecs.berkeley.edu Fri Jul 20 02:06:20 2001 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Thu, 19 Jul 2001 18:06:20 -0700 (PDT) Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? Message-ID: [First, I have to apologize in advance; I think this post a rant. Now that I've written it, it really doesn't touch on Python, although it hints at the role of CP4E.] Recently, the Potomac Tech Journal published an article: "Universities aren't serving the IT workforce" http://www.potomactechjournal.com/displayarticledetail.asp?art_id=48819&sec_id=95 which I found offensive in the article's attitude toward computer science education. The article seems to argue that CS education should cater more towards the IT workplace, removing prerequesites that are not "needed by business". He uses his son as an example of how CS education has failed him. """My son now attends Boston College, majoring in business and computer science. After one semester of computer science, he decided he didn't care for the heavy math concentration, in spite of the fact that he loves to write code and has done so for several years. Another IT worker lost.""" My argument with the article is that it assumes that the charter of a computer science education is to make good little IT tech workers. It seems to ask "What good is education?" Didn't Pythagoras or Euclid have to deal with this attitude once? If CP4E ever becomes widely implemented, will educators also have to defend what they teach on the basis of direct application? I don't think application training is what computer science should primarily be about. If one wants to find a place to get IT training, the trade schools are simply a more appropriate place. On the other hand, computer science should expose students to ideas as well as techniques. In short: it should be dense but filling. Furthermore, the article's view of computer science completely ignores the role that mathematics plays in CS. For example, computer graphics uses linear algebra and artificial intelligence uses logic --- both would be empty calories without the technical content. These two fields are significant, even in a business setting, and it seems a very shallow view to restrict an CS education to "IT". The author concludes with: """Our colleges and universities are supposed to be training the workers of the future. Despite the current soft economy, well-educated technology workers will be in demand for many years to come, so institutions of higher education would be wise to make curriculum adjustments now in order to meet this long-term demand.""" If direct applicability is the article's argument, then even the author must admit that some "theory" is necessary to create a well-educated and effective workforce. Still, even with the shallowness of the argument, the article still touches on an attitude that seems common: what good is education if it cannot be applied? From wilson@visi.com Fri Jul 20 02:47:26 2001 From: wilson@visi.com (Timothy Wilson) Date: Thu, 19 Jul 2001 20:47:26 -0500 (CDT) Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? In-Reply-To: Message-ID: On Thu, 19 Jul 2001, Danny Yoo wrote: > He uses his son as an example of how CS education has failed him. > > """My son now attends Boston College, majoring in business and computer > science. After one semester of computer science, he decided he didn't care > for the heavy math concentration, in spite of the fact that he loves to > write code and has done so for several years. Another IT worker lost.""" IANACS (I am not a computer scientist), and I may not be using the correct terminology, but isn't there a difference between computer science and software engineering? Isn't computer science, by definition, the study of the mathematical aspects of algorithms, etc. Software engineering, on the other hand, would seem to be focused more directly on developing software. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.org W. St. Paul, MN | | http://slashdot.org wilson@visi.com | | http://linux.com From agauld@crosswinds.net Fri Jul 20 11:52:31 2001 From: agauld@crosswinds.net (Alan Gauld) Date: Fri, 20 Jul 2001 11:52:31 +0100 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? Message-ID: <3b580d9d.80eb.0@crosswinds.net> Pah, finger trouble meant the first attempt at a reply got blitzed half way thru', if it turns up ignore it, sorry... >I think this post a rant. Thats OK I had one on a related them a few months ago. Partly based on the response to that I'll chip in here. >Recently, the Potomac Tech Journal published an article: > > "Universities aren't serving the IT workforce" >... > which I found offensive in the article's attitude > toward computer science education. I think the article is understandable and I agree with the underlying sentiment. I think the autheor is simply revealing a fundamental misunderstanding of what Computer Science is about as a subject. What he is really lamenting is the lack of a computer engineering discipline. Thus we have the equivalent of Chemistry being taught but no Chemical Engineering. I know some colleges have a subject variously labelled computer engineering or software engineering but in practice these seem to be very thin on engineering and mainly a kind of "pragmatic CS". The writer is correct in that the IT industry is screaming for grad level IT workers in computing but not always in those areas involveed in writing software - which is where CS is still focussed. There simply are no courses that cover computer hardware, configuration, networking, performance tuning etc etc. Where I disagree with the writer is in his dismissal of math, since math is vital in almost all aspects of computing including the hardware/networking elements. You may not use it in everyday work - most electrical engineers would say the same! But to acquire real understanding of the principles you must have the math... Whether the math needs to be quite so heavy as it seems to be is debateble - that seems like a heridary aspect of computing originally being a branch of math in most universities. > My argument with the article is that it assumes that > the charter of a computer science education is to > make good little IT tech workers. I think there is a responsibility on university computer departments to produce the IT engineers that are needed and they are simply not doing that. The CS courses have split into those that have become so esoteric in their algenbraic/algorithmic/computational(in the math sense) focus that they are of little pracxtical relevance and those that have simply tried to produce cannon fodder for the programming/software develoment industry (the subject of my own rant). The problem is that as industry builds ever computing systems of ever greater complexity there are no graduates available who can understand how or what its about. Industry in effect has to bear the cost of training which in other engineering disciplines is done at univversity level. The telecoms indiustry was in a similar position about 20-30 ytears ago with telcos providing huge amounts of basic theory simply because EE coursew didn't teach the networking/switching stuff needed. As the Telecomms sector exploded colleges reacted to that and there are now specialist telecomms degrees available in most places. The Computing industry is cryiong out for the same kind of change to happen. > It seems to ask "What good is education?" I don't think so, I think it asks why is the education so impractical? When the subject name would suggest it should be one of the most practical of subjects to study! Nobody expects a course on prehistorc music to be practical but CS students might be expected to emerge with a degree which teaches them about computing in the modern context rather than a purely theoretical understanding of mathematical computation and irs application to machines. > If CP4E ever becomes widely implemented, > will educators also have to defend what they teach > on the basis of direct application? My understanding of CP4E was that its justification was precisely the programming was a practical skill and didn't neeed lotsof esoteric background math etc. Indeed my concern with CP4E is that it may not in fact be possible to really teach programming without at least basic math. The real problem as I see it is that CS has not apparently grasped that computing as a subject is about much more than programming. >I don't think application training is what computer > science should primarily be about. Nor I but IT workers don't generally run applications - they worry about security, network loading, CPU loading, RAM usage etc etc - who teaches that stuff? Whe teaches how to size a computer or network to run a set of programs? What about network management - MIBs, event monitoring, resource management etc etc. This stuff is simnply ignored by most computer departments and yet is the biggest single cost for most IT departments - much more than that of software development! >... the article's view of computer science completely > ignores the role that mathematics plays in CS. Here I agree and it is very disappointing that the professors he spoke to could not do a convincing job of persuading him of the need for math. >to restrict an CS education to "IT". Again there is a need IMHO for a new degree discipline of IT. CS does not address this area well, if at all. But then neither does anyone else! Thats why it has become black magic with a few guru's ruling the roost based on years of experience. Thats why the famous series of spoof articles the "operator from hell" ring so true to life. > the article still touches on an attitude that seems > common: what good is education if it cannot be applied? Education serves two purposes - to inform and to train. The IT industry needs the training aspect and isn't getting it. The academic community, if it wishes to be paid to inform, needs to provide the training too. In this it is singularly failing at present. If the current trend continues I can fortesee many large businesses withdrawing the current high level of funding/grants/sponsorship given to CS departments because they are simply not seeing the required return on investment! Alan G. From com-nospam@ccraig.org Fri Jul 20 14:12:58 2001 From: com-nospam@ccraig.org (Christopher A. Craig) Date: 20 Jul 2001 09:12:58 -0400 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? In-Reply-To: <3b580d9d.80eb.0@crosswinds.net> References: <3b580d9d.80eb.0@crosswinds.net> Message-ID: <87elrbn3qd.fsf@elbereth.ccraig.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Alan Gauld" writes: > I think the article is understandable and I agree with > the underlying sentiment. I think the autheor is > simply revealing a fundamental misunderstanding of > what Computer Science is about as a subject. > > What he is really lamenting is the lack of a computer engineering > discipline. Thus we have the equivalent of Chemistry being taught > but no Chemical Engineering. I disagree that this is what the author is stating. I know people who majored in Chemical Engineering and they had to take differential equations, electro magnetism, computer science, English, etc. All of which are useless to their jobs, just like "calculus, linear algebra, physics and differential equations" (quoting the author) are to most CS jobs. He asserts that because 95% of "IT jobs" don't require them that they should not be required of a CS major. This flies in the face of the entire university ethic. Most jobs working on airplanes will never need high-level physics, differential equations, calculus, or chemistry but I bet if you check the curricula of the top 10 Aerospace Engineering schools in the country you will find all of these courses listed. This is because a university is not a technical school. If you want to learn how to do a job in the IT field, you should go to a technical school. If you want to learn about the science of computation you should go to a major university. The job of universities is not to fill the openings of the millions of Java weenies and NT administrators that are in the industry, it is to educate people. While I was in college I met quite a few people who whined about how they didn't have a class in , or they had to take "useless" classes in . I never understood why they didn't transfer to a school that offered what they wanted. I think the problem is not the universities themselves, but rather the light with which universities and technical colleges are viewed. I think many people currently look down on technical schools as being basically just like universities, but for the people who couldn't get into universities. This isn't a very useful view. I know several people with associates degrees from technical schools, they aren't dumb. They just wanted to gain immediately useful skills, and didn't care how to prove that the recursion 5*j+1 modulo 2**i is a cyclic group of order 2**i (or what the last half of that sentence meant) It would be better if people saw technical college as places to get skills currently needed in the industry (or people with said skills), and universities as places to further your education in the base theory of a certain field (whether that field is CS or Mechanical Engineering). - -- Christopher A. Craig If Perl weren't around, I'd probably be using Python right now. Tom Christiansen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt iEYEARECAAYFAjtYLloACgkQjVztv3T8pztG3wCeLgPYiwYx0b61258zINCaS8tj +wMAoL3rmw2LA6VNs6jIUrKQlfWgNqUn =YhCT -----END PGP SIGNATURE----- From rob@jam.rr.com Fri Jul 20 14:46:38 2001 From: rob@jam.rr.com (Rob Andrews) Date: Fri, 20 Jul 2001 08:46:38 -0500 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? In-Reply-To: <3b580d9d.80eb.0@crosswinds.net> Message-ID: # -----Original Message----- # From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On # Behalf Of Alan Gauld # Sent: Friday, July 20, 2001 5:53 AM # To: Danny Yoo; edu-sig@python.org # Subject: Re: [Edu-sig] Computer science without all that "heavy math" # stuff...? # # # The CS courses have # split into those that have become so esoteric in their # algenbraic/algorithmic/computational(in # the math sense) # focus that they are of little pracxtical relevance and # those that have simply tried to produce cannon fodder # for the programming/software develoment industry (the # subject of my own rant). In all honesty, all the Computer Science and Software Engineering people I know call me to work on their hardware, home LANs, and a great many technical problems. (Most of the time they spend a few days really destroying things before they admit that they're in over their heads. They scoff at my love of Python while expressing frank amazement at my ability to handle the practical tasks that leave them baffled. My best friend had to get through Calculus III, write a compiler, generate working binary and hex code, and many other arcane facts while working on his CS degree. And compared with the other career programmers I've met, he's the most capable with actual computers and networks. But he's still basically clueless in comparison with a host of barely-literate PC jocks I have known. However, my IT skills (learned almost exclusively hands-on, since my Psychology and Philosophy degree are only of peripheral value) seem Liliputian in comparison with the advanced material they know (and actually do use). # # The problem is that as industry builds ever computing systems of # ever greater # complexity there are # no graduates available who can understand how or what # its about. Industry in effect has to bear the cost of # training which in other engineering disciplines is done at # univversity level. # # # The telecoms indiustry was in a similar position about # 20-30 ytears ago with telcos providing huge amounts of # basic theory simply because EE coursew didn't teach the # networking/switching # stuff needed. As the Telecomms # sector exploded colleges reacted to that and there are # now specialist telecomms degrees available in most # places. The Computing industry is cryiong out for # the same kind of change to happen. # # > It seems to ask "What good is education?" Maybe colleges and universities can produce quality IT workers if they try. I have no idea. When hiring new technicians, I can honestly say that I have never met a trade-school IT graduate of any clear value as an employee. I have had to sadly turn people away at the door because I do not have the time to train someone with A+ certification on how to replace a video card or locate updated drivers on the web. In at least one major corporation with its head office in the Jackson, Mississippi area, written policy dictates that new hires (for Software Engineer positions) with CS degrees be hired at a lower pay scale than those with SE degrees, and related salary caps apply. The official statement is that this applies regardless of actual technical skill. Apparently, the desire is not to have to train the CS grad in engineering concepts (like a variant of my denial of the trade/vocational schools). # # I don't think so, I think it asks why is the education # so impractical? When the subject name would suggest # it should be one of the most practical of subjects # to study! Nobody expects a course on prehistorc music # to be practical but CS students might be expected to # emerge with a degree which teaches them about # computing in the modern context rather than a # purely theoretical understanding of mathematical # computation and irs application to machines. # # > If CP4E ever becomes widely implemented, # > will educators also have to defend what they teach # > on the basis of direct application? # # My understanding of CP4E was that its justification was precisely # the programming # was a practical skill and didn't neeed lotsof esoteric background # math etc. # Indeed my concern with CP4E is that it may not in fact be # possible to really # teach programming without at least basic math. # I am actually taking the opposite approach. Having not been exposed to much math, I use Python and other programming languages to teach me math. It provides some meaningful context, enabling me to see why mathematics is important and can be useful. Every cheezy little script I can write (and the ones that fail, as well) teaches me more about computing and how it works. I actually find that some of the advanced theory I learned even in Psychology and Philosophy becomes tangibly useful when I sit down to code. The obscure theoretical material is important, even if not visibly so. And I mostly program for simple pleasure. # The real problem as I see it is that CS has not apparently # grasped that computing # as a subject is about much more # than programming. # # >I don't think application training is what computer # > science should primarily be about. # # # Education serves two purposes - to inform and to train. # The IT industry needs the training aspect and isn't # getting it. The academic community, if it wishes to # be paid to inform, needs to provide the training too. # In this it is singularly failing at present. If the # current trend continues I can fortesee many large # businesses withdrawing the current high level of # funding/grants/sponsorship # given to CS departments # because they are simply not seeing the required # return on investment! Is there any real truth to what I've heard along the lines that "really qualified people working in Software Engineering often hesitate to take a massive pay cut to share critical skills in the University"? -Rob "I do remain confident in Linda. She'll make a fine labor secretary. From what I've read in the press accounts, she's perfectly qualified." -- George W. Bush Useless Python: http://www.lowerstandard.com/python/ From pdx4d@teleport.com Fri Jul 20 16:29:13 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Fri, 20 Jul 2001 08:29:13 -0700 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? In-Reply-To: References: Message-ID: <4.2.0.58.20010720080844.00be38a0@pop3.norton.antivirus> I think a worthwhile CP4E trajectory is to phase more Python into a standard math curriculum. Learn math with a computer language at your elbow. CP4E does *not* mean "CS for everybody". And to learn some programming is not to turn yourself into a professional programmer if that's not where you want to go -- any more than learning some biology and first aid skills commits you to becoming a medical doctor. Students entering the higher level U-type courses would have more background in the relevant math/computer concepts. Here's a pre-university math curriculum I posted to k12.ed.math the other day, in which Python might feature: =========== Intro to Number Theory primes + composites gcd lcm totient mod operation Intro to Programming (Python) boolean algebra bases 2,8,16 operator overriding -- class/object concepts -- build a fraction object, using above (adds/subtracts, multiplies/divides rationals) residue classes and more operator overriding initial group, ring, field discussion cryptology thread Sequences and series: sigma notation triangular and square numbers tetrahedral and cubic numbers etc. recursive definitions (e.g. Fibonacci) Functions: domain, range, function, inverse functions inverse as negation vs. reciprocation -- reinforce group, ring, field concepts Preview of trig and exponential functions cos,sin,tan,exp plus inverses linear functions and polynomials delta f(x)/delta x = slope, preview of derivative Polynomials and complex plane, fractals Build a polynomial object Pascal's Triangle: permutations and combinations (factorial notation) Gaussian distribution, averages, standard deviation binomial theorem -- link back to polynomials Bernoulli numbers Polygons and Polyhedra: trig functions (reinforce inverse functions) angle vs. size (shape vs. volume) -- rates of change rotational symmetry groups (phi - Fibonacci - Pascal's Triangle) rotation matrices Fuller's concentric hierarchy CCP HCP BCC SCP (sphere packings - crystals) More advanced electives: More calculus: convergence infinite series approximations (Newton's and LaGuerre's Method) physics concepts (velocity, acceleration, energy, power) Spherical trig: cartography GPS Computer graphics: still (rendered) and dynamic Simulations and Modeling: modeling software, Forrester-type concepts, discussion of chaos/complexity mathematics Narratives: Evolution of cryptography in tandem with computer machinery. WWII, Enigma and Bletchley Park, the discovery of public key cryptography and the spread of new algorithms. Gives an application for group and number theory. Evolution of computers and programming paradigms. Helps foster an understanding of the feedback loop between mathematics and computer science as related disciplines. Evolution of polynomials and finding their roots. Invention of negative and then complex numbers. Galois and Gauss's construction of the 17-gon. Explains expansion of the number system. Evolution of vector algebra concepts, including the invention of quaterions and Clifford algebra. Links algebra to geometry. Macro and microarchitecture: geodesic domes, the virus and buckminsterfullerene (also quasicrystals). Octet truss, Alexander Graham Bell and the FCC [means face- centered cubic lattice, not Federal Communications Comission]. Gives insight into spatial relationships, a basis for "mental geometry" (vs. mental arithmetic). Evolution of the calculus in a physics context, along with the story of supplying a logical framework for continuous (vs. discrete) mathematics. Gives insight into mathematics as an evolving discipline. Context: http://www.mathforum.com/epigone/k12.ed.math/golspiglax =========== Beyond this, I'm a big fan of field experience mixed with coursework (a.k.a. work-study). As the not-for-profit sector gets higher tech, it gives para-professionals opportunities to hone skills in more volunteer-like capacities, perhaps apprenticing under those with more experience. This is how many have used their military experience, but I'm also talking civilian sector opportunities -- e.g. learn some IS skills in the Peace Corps, in Burundi. Kirby From agauld@crosswinds.net Fri Jul 20 16:56:00 2001 From: agauld@crosswinds.net (Alan Gauld) Date: Fri, 20 Jul 2001 16:56:00 +0100 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? Message-ID: <3b5854bc.a4fe.0@crosswinds.net> >> What he is really lamenting is the lack of a computer >> engineering discipline. >I disagree that this is what the author is stating. Sorry, I dodn't mean thats what he was statiing I meant that was the underlying lack at which he was intimating. In other words he is asking CS to teach something that is inappropriate for a science. It would however be appropriate for an engineering degree. > I know people who majored in Chemical Engineering > and they had to take differential equations, ... Absolutely, and that's still approprioate for an IT/Computer engineering degree. I strongly believe that. I don't think the author undestood the inevitably mathematical nature of computer engineering (or of any form of engineering for that matter!) but leaving the math issue aside I do think he is write to highlight the fairly narrow view of computing that seems to be taken by CS courses - namely programming! > He asserts that because 95% of "IT jobs" don't > require them that they should not be required > of a CS major. Yes, and that I don't agree with. I think he, like many lay people, doesn't appreciate what any scientific or engineering degree is about in that respect. >If you want to learn how to do a job in the IT field, > you should go to a technical school. Sorry, that doesn't make sense. Most programmers come from a CS degree background(at least herabouts they do) and programming is part of the IT field. The problem is that IT has moved on from a cottage industry where everyone knew everything to a huge field with many specialisms. The difficulty is that the diversity is not mirrored in CS courses which are still largely focussed on software development as if that was all computing was about. > java weenies and NT administrators I do find this a tad offensive to the many people involved in the IT industry who are not programmers. Computing operations is a big and complex business which requires a broad and deep knowledge of computers, networks and how they operate and interact - something of which most graduate programmers are woefully ignorant and it shows up in the non-scaleable, unmaintainable code that they produce! > whined about how they didn't have a class in > , or they had to take > "useless" classes in . That happens on any course but the concern that I have here is that many CS courses are caving in to that by focussing purely on the commercial demands without providing the theory. We need both! > I think the problem is not the universities > themselves, but rather the light with which > universities and technical colleges are viewed. I think thers a bit of that, but I also believe that the CS departments are too slow to broaden the range of computing subjects they teach. Alan G From Arthur_Siegel@rsmi.com Fri Jul 20 17:43:36 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Fri, 20 Jul 2001 11:43:36 -0500 Subject: [Edu-sig] re: Computer science without all that "heavy math" stuff...? Message-ID: <00861747.N22121@rsmi.com> >I am actually taking the opposite approach. Having not been exposed to much >math, I use Python and other programming languages to teach me math. It >provides some meaningful context, enabling me to see why mathematics is >important and can be useful. Every cheezy little script I can write (and the >ones that fail, as well) teaches me more about computing and how it works. I >actually find that some of the advanced theory I learned even in Psychology >and Philosophy becomes tangibly useful when I sit down to code. The obscure >theoretical material is important, even if not visibly so. And I mostly >program for simple pleasure. Sounds quite similar to my experience. My Python and math evangilism have become quite intertwined - as Python became for me a tool that has made math accessible in quite fresh and exciting ways. Quite strange how we have gotten math tucked into some corner. Perhaps it is my own make-up, but I have come to see it as the finest kind of exercise of the imagination. In my opinion, it is tragic that math has become so isolated from the Liberal Arts education. That much harder to sympathize with the plea to isolate it from a CS education. ART From kevino@tulane.edu Fri Jul 20 17:34:03 2001 From: kevino@tulane.edu (Kevin Ollivier) Date: Fri, 20 Jul 2001 12:34:03 -0400 Subject: [Edu-sig] re: Computer science without all that "heavy math" stuff...? References: <00861747.N22121@rsmi.com> Message-ID: <002c01c11139$ca1eaaa0$2101a8c0@kevinnew> This has also been my experience. Calculus made much more sense to me after I learned to program. I think it is because programming forces you to learn the concepts of abstraction, logic, sequencing, functions, etc. and at the end of the day you use these techniques to create solutions to problems. It wasn't until after I programmed for a while that I saw algebraic equations as a way of modelling relationships - before I always would look at a formula and think 'how did they come up with this?' Now I saw they were just, in their own way, building a program to model mathematically a real-world relationship and use that to predict or measure the effects of change. It definitely helped me to appreciate their work more. Math classes generally take the 'function cram' approach - which I would consider akin to making one try to memorize the entire Python library API rather than teaching how to program. Even the "problem solving" questions in the book aren't very helpful - they often ask you to do things you would never do in real life. "Calculate, using formula x, the distance of the ambulance from you at 2, 5, and 8 seconds." Or, "You see a plank of wood sitting against a wall. Now, you're extremely bored, happen to have a measuring tape with you, and are curious about the exact angle that piece of wood is stationed at. Find the angle where the wood connects to the ground." These examples are brain teasers, but they don't give students an idea about how they can use these things in real life. Not to mention, most teachers avoid those questions because students have lots of problems with them. Of course, school teaches a high-level of math to many people who may never have to use it - thus how can you give relevant examples? I honestly believe that abstract thinking is a skill in itself and needs to be gained by anyone getting into programming or math as a career. Anyways, just thought I would throw in my two cents. Kevin Ollivier ----- Original Message ----- From: To: Sent: Friday, July 20, 2001 12:43 PM Subject: [Edu-sig] re: Computer science without all that "heavy math" stuff...? > >I am actually taking the opposite approach. Having not been exposed to much > >math, I use Python and other programming languages to teach me math. It > >provides some meaningful context, enabling me to see why mathematics is > >important and can be useful. Every cheezy little script I can write (and the > >ones that fail, as well) teaches me more about computing and how it works. I > >actually find that some of the advanced theory I learned even in Psychology > >and Philosophy becomes tangibly useful when I sit down to code. The obscure > >theoretical material is important, even if not visibly so. And I mostly > >program for simple pleasure. > > Sounds quite similar to my experience. > > My Python and math evangilism have become quite intertwined - as Python > became for me a tool that has made math accessible in quite fresh and > exciting ways. > > Quite strange how we have gotten math tucked into some corner. > Perhaps it is my own make-up, but I have come to see it as the finest kind > of exercise of the imagination. > > In my opinion, it is tragic that math has become so isolated from the Liberal > > Arts > education. That much harder to sympathize with the plea to isolate it from a > CS education. > > ART > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > http://mail.python.org/mailman/listinfo/edu-sig > From com-nospam@ccraig.org Fri Jul 20 17:49:51 2001 From: com-nospam@ccraig.org (Christopher A. Craig) Date: 20 Jul 2001 12:49:51 -0400 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? In-Reply-To: <3b5854bc.a4fe.0@crosswinds.net> References: <3b5854bc.a4fe.0@crosswinds.net> Message-ID: <87k813lf4g.fsf@elbereth.ccraig.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Alan Gauld" writes: > The difficulty is that the diversity is not mirrored in CS courses > which are still largely focussed on software development as if that > was all computing was about. I don't think I've seen this. The specializations offered at Georgia Tech include networking, computational math, operating systems (design), compiler design, database systems, and human-computer interaction. Now all of these also teach programming and basic programming tenets (including objects, concurrent programming, etc), but their higher level classes focus on things outside the area of software development. > > java weenies and NT administrators > > I do find this a tad offensive to the many people > involved in the IT industry who are not programmers. Yes, I apologize for that. I named these as examples (bad ones) of jobs for which most companies don't care if you have a background in math or theory and not to insinuate that non-programmers (myself included) were somehow inferior to programmers. I was intending to say that if you wanted to go into a computing job that does not require knowledge of math or underlying theory, perhaps you would be better off without a university that stresses the underlying theories of everything. Perhaps I could have paid attention more in my university writing classes. :-) > > whined about how they didn't have a class in > > , or they had to take > > "useless" classes in . > > That happens on any course but the concern that I have here is that > many CS courses are caving in to that by focussing purely on the > commercial demands without providing the theory. We need both! Agreed, and my beef with the author is that I think he was essentially proposing that universities do exactly that. > I think thers a bit of that, but I also believe that the CS > departments are too slow to broaden the range of computing subjects > they teach. I have never thought about this before, but it certainly is a valid point. I only have experience with one university, and I thought that their curriculum was fairly well diversified, but even it did focus on programming and so I can definitely see how this could cause a problem. (though the author did a bad job describing this, if he even did describe the same problem). - -- Christopher A. Craig "Going to school make a person educated, any more than going to a garage makes a person a car" Slashdot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt iEYEARECAAYFAjtYYS8ACgkQjVztv3T8pzsM9ACfQNDbDHlrn/c+XdxWpzZGPmEw SzMAoJlHNkGSs1vznb9YSEd5nGTo/ZZe =dDuX -----END PGP SIGNATURE----- From delza@alliances.org Fri Jul 20 18:12:28 2001 From: delza@alliances.org (Dethe Elza) Date: Fri, 20 Jul 2001 10:12:28 -0700 Subject: [Edu-sig] Computer science (long, rambling) References: Message-ID: <3B58667C.2040505@alliances.org> Here's my story about CS degrees: I went to an alternative high school where you had to be very self-motivated in order to graduate. About this time, Reagan was elected and all funding dried up. The school closed in 1983 after 12 years in operation. This was my third year and I didn't have the credits to graduate, so I chose to drop out rather than re-enlist in traditional school. Math was one of the credits I didn't have. Finally got my GED in 1984 so I could go back to school. I went to a technical school in emergency medicine. It was OK, but I decided I didn't want to be an ambulance driver, a decision driven home when I had an automobile accident on my way to class one day. Dropped out for a while. Went back to school at University, in Physics because I'd been reading the Tao of Physics and related works, I immediately discovered that college-level physics has nothing to do with all that and I'd about two years of math before I could take my first physics course. Switched majors to Creative Writing. My family was paying for me to go to school, in hopes that I would get scholarships or grants or something. Unfortunately, I hated paperwork. After awhile they stopped paying and I dropped out again. Spent about five years, mostly washing dishes for a living. Finally got a job 12 hours a week typing reports for the local hospice. We were sharing an Apple II with the visiting nurses association. It turns out that typing in Junior High was the most important class I ever took, because everything else came from that. I worked my way up from typist to full time secretary to office manager. Along the way, a much larger hospice donated some software for running a hospice, mainly handling billing, but it ran on a PC which we didn't have. So for two months I read every PC magazine I could find, learned the jargon and requirements, and wrote up my findings. My boss added a cover letter and that was our grant application. We got the grants, installed the software, and got our records and billing processes moved over to it (this was a 286 running DOS and Windows 2.0). I began to think this computer thing might have a future in it--the idea of getting paid for what I enjoy doing had been pretty alien to me before. Left hospice and did some consulting, setting up computers, problem-solving. Got another job typing, mostly resumes, temped in a law office. Eventually I ended up washing dishes again, but this time as a worker-owner of a cooperatively-run restaurant. Decided it was time to get a degree. I was thinking I'd go into Math because no matter what I studied (architecture, physics, music, etc.), I kept coming up against the wall that I didn't have Math as a language. I didn't figure I needed to go into CS because I could learn computer stuff on my own. Wiser friends persuaded me to go into CS. Left the restaurant business (one of the few jobs I miss) and began selling Macintoshes and working as a TA babysitting the computer lab. Learned that there were two kinds of students in CS: Those who were genuinely interested in computers and had their own projects on the side and would pick up new languages and skills because they needed them or were curious, and those who were there to get a lucrative career, did the minumum to not flunk out, and would eventually be the managers of the others. I also noticed a common dynamic in the university: Engineering students who couldn't hack it became CS students. CS students who couldn't hack it became MIS students. I don't know what happened to MIS students who couldn't hack it. Interestingly enough, I found freedom of expression was tolerated much more in CS than in the creative writing department. OK, now we finally get to the math part. Thanks for hanging in with me. CS required four quarters of Calculus, but it wasn't a pre-requisite for any of the CS classes, just for graduation. Having had no math classes since junior high, I had to take three classes just to get to Calculus, beginning with Math 101. Math 101 was basically a rehash of what I'd covered in Junior High 10 years earlier, and it was filled mostly with non-traditional students. I often found myself translating the teacher's math-speak back and forth with the other students: The teacher couldn't understand them and they couldn't understand him, even when they were both saying the same thing. This lead to the teacher suggesting that I major in Math, which I found amusing, "Dude, I'm in *remedial* math!" None of the computer science classes I took mentioned math until my last quarter when I took a graphics class and we were expected to know Linear Algebra (which wasn't a requirement). It was the first experience I had in CS where they showed us how any of the math we'd learned could be applicable to real problems. This class was an elective and was taught by the worst teacher in the department, who sensible people avoided like the plague (I had previously sworn never to take a class with him again, but I never listen to my own advice. Oh, and he was my academic advisor, a role which made his teaching look good by comparison.) Now logic was something we used all the time. I'd taken logic in my earlier incarnation as a creative writing major, and it was taught by the philosophy department, not the math department. Needless to say, this was not a requirement (or even a strong suggestion) in the CS curriculum. Graduating from CS, I did one of the most reckless things of my entire life: I reinlisted for a Master's degree. At this time there was a slow-motion coup going on in the CS department. Until this time there was no official CS MS degree program, just a math degree with "emphasis on computer science." The junior professors were dissatisfied with this, while the older professors (who all came from math or philosophy backgrounds) were happy with it. The junior professors won and we got more than we bargained for: The entire CS program was taken out of the college of arts and sciences and moved to the college of engineering. We would all be engineers now! (Actually, my first quarter as a grad student was still in the math department. I wanted to seek out my Math 101 teacher and say, "Look, you were right. I'm a graduate student in math now!" But I didn't.) Of course, no one knew how this would work, so the five of us who stayed on after our bachelor's degrees became guinea pigs for the new program. The new degree was "Electrical and Computer Engineering," and we were thrust into crash courses in EE (for which we didn't have even the barest traces of the required math), circuits, hardware logic, parallelism, physical networking (ethernet and it's kin, as opposed to TCP/IP and its kin), etc. Then we would trudge back to the math building for our CS classes. There was no continuity, and while there was one CS class which touched on math skills (Algorithms), I think it would still have been over our heads even if we'd had the experience with maths and proofs. On the other hand, our EE classes were mostly applied math and logic, ranging from the simplistic to the brain-defying. Since graduation I have worked at Lucent programming CORBA interfaces for monitoring telephone networks, at various internet startups, programmed servers and clients, databases and 3D visualization tools, installed hardware, monitored networks, written code in umpteen different languages, mentored junior developers, and taught some continuing ed. classes. I still find I come across a need for math more often in my personal studies than in my work, but knowledge of math, especially a deep, intuitive knowledge of math, helps in the day to day, probably in ways I'm not even consciously aware of, but see in the work of people who lack it. Logic still plays a greater role than calculus (even when I was doing 3D). I should have taken statistics in college, I'm being forced to learn them bit by bit over the years and it would have been less painful to take them as one bitter pill. I've also had the pleasure to work with some fine people over the years. Some of them came from technical schools, many from CS programs, a few had Ph.Ds, quite a number had no official computer education at all. What made them good at their jobs, good with computers, is a deep-seated interest in computers. The very best were interested in people more than computers, but the interest in computers had to be there. Somehow I feel all of this should lead to why I love Python so much. Perhaps it does. My wife, with no programming experience and whose computer experience is limited to email and word processing (now branching out into weblogging), has written a Python program to compare mortgages. There is this tendency in our society to see computers as something more than what they are. People like to use computers as metaphors for the brain, to see them as living things, or powerful forces (for good or ill), but really, computers are just tools. Fantastically complicated and flexible tools, but just tools. Like all tools, computers are good for some tasks and not for others. People who are going to be good IT workers are the ones who realize this, who *regardless of their education* have an interest in these tools and making them work better for people. Those are the two keys: Interest in constantly learning more about these complex tools, and interest in making them work better FOR PEOPLE. OK, sorry for the long post, didn't have time write a shorter one %-) --Dethe -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) From erburley@ix.netcom.com Sat Jul 21 21:12:18 2001 From: erburley@ix.netcom.com (Brent Burley and Pat Erb) Date: Sat, 21 Jul 2001 13:12:18 -0700 Subject: [Edu-sig] fun w/ word list Message-ID: <000e01c11221$75db1f80$4c53d8ce@68k2f01> One of the things I enjoyed while learning to program was playing with a spell check library (anyone remember Borland's Turbo Lightning?) and writing various word filters. This is now trivial in python: >>> words = open('/usr/share/dict/words').readlines() >>> words = [w[:-1] for w in words] # strip newline chars >>> def aeiou(w): # return true if word uses every vowel ... f = string.find ... for c in 'aeiou': ... if f(w, c) == -1: return 0 ... return 1 >>> filter(aeiou, words) ['adventitious', 'aeronautic', 'ambidextrous', 'argillaceous', 'argumentation', 'auctioneer', 'audiotape', 'augmentation', 'aureomycin', ...] Other ideas: - find palindromes - find the words with the most number of each letter - find words with no vowels - find the word with the most vowels/consonants in a row - make a histogram of letters used - find words whose reverse is a word - build a crossword puzzle solver Most systems have a word list, but perhaps not in the location shown above. Try 'man spell' and look in the FILES section. Brent Burley From cmeyers@guardnet.com Sun Jul 22 02:59:32 2001 From: cmeyers@guardnet.com (Chris Meyers) Date: Sat, 21 Jul 2001 17:59:32 -0800 Subject: [Edu-sig] fun w/ word list Message-ID: Hi Brent, Yes, these are fun. In Python for fun, the user input module has some stuff like this. Mainly spell check in Python. If anyone needs a word list file you can download http://www.ibiblio.org/obp/py4fun/spell.tar.gz It's all of about 180Kb compressed. Here's a little challenge for anyone. Do you know the "Jumble" in some newspapers where you have figure out that "ygenxo" is the word "oxygen"? Actually many people miss that one. Write a bit of Python that solves these like single lookup instantaneously! Chris 07/21/2001 2:12:18 PM, "Brent Burley and Pat Erb" wrote: >One of the things I enjoyed while learning to program was playing with a >spell check library (anyone remember Borland's Turbo Lightning?) and >writing various word filters. This is now trivial in python: > >>>> words = open('/usr/share/dict/words').readlines() >>>> words = [w[:-1] for w in words] # strip newline chars >>>> def aeiou(w): # return true if word uses every vowel >... f = string.find >... for c in 'aeiou': >... if f(w, c) == -1: return 0 >... return 1 >>>> filter(aeiou, words) >['adventitious', 'aeronautic', 'ambidextrous', 'argillaceous', >'argumentation', 'auctioneer', 'audiotape', 'augmentation', >'aureomycin', ...] > >Other ideas: >- find palindromes >- find the words with the most number of each letter >- find words with no vowels >- find the word with the most vowels/consonants in a row >- make a histogram of letters used >- find words whose reverse is a word >- build a crossword puzzle solver > >Most systems have a word list, but perhaps not in the location >shown above. Try 'man spell' and look in the FILES section. > > Brent Burley > > >_______________________________________________ >Edu-sig mailing list >Edu-sig@python.org >http://mail.python.org/mailman/listinfo/edu-sig > From dyoo@hkn.eecs.berkeley.edu Sun Jul 22 04:01:48 2001 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Sat, 21 Jul 2001 20:01:48 -0700 (PDT) Subject: [Edu-sig] fun w/ word list In-Reply-To: Message-ID: On Sat, 21 Jul 2001, Chris Meyers wrote: > Yes, these are fun. In Python for fun, the user input module has some > stuff like this. Mainly spell check in Python. If anyone needs a word > list file you can download > > http://www.ibiblio.org/obp/py4fun/spell.tar.gz Is this similar to the "words" text file that Don Knuth prepared for his "Stanford Graphbase" project? http://www-cs-faculty.stanford.edu/~knuth/sgb.html As one example, Knuth compiled a list of common 5-letter words that he used to test combinatorial algorithms. Perhaps this word list could be incorporated into the py4fun project: ftp://labrea.stanford.edu/pub/sgb/words.dat From Arthur_Siegel@rsmi.com Sun Jul 22 17:01:08 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Sun, 22 Jul 2001 11:01:08 -0500 Subject: [Edu-sig] PEP0238 lament Message-ID: <00867F2E.N22121@rsmi.com> Before going further in attempting to contribute to the discussions of Pep238 (or case sensitivty) allow be to present my credentials. None, to speak of. Except that I've been through the program. Guido's program. His language. His environment. His tutorials. I think with some success. Participate little on python-list, because much of what goes on is over my head. But on the question of learning programming with Python - as I mention, been through the program. Here the issues are under my nose, not over my head. I particpate actively on the edu-sig list, because I understand my success could be other's success. Am a big supporter of Guido's CP4E ideals. Yet despite the gratitude I try to keep in mind, I clash consistently with Guido on CP4E - sometimes in unpleasant ways. Can only hope he appreciates at some level that I bring some passion to the table on some common goals. Because that clash now spills over to the Python list. Since I have convinced myself that not only do I object to the rationale and evidence gathering behind the integer division change - I am going to step up and be arrogant enough to say that I am against it as a design feature, in light of the only aspect of Python design about which I would dare to speak - CP4E goals. 3 / 4 = 0 3.0 / 4 = .75 Something important is going on here. I have a decent understanding of what that is. Enough to get me by in the real world. I came to It - having already understood that I would only get so far if I expected it all to come to me. That reckoning has been put off an hour ot two for the Python 2.2 learner, with a measurable cost. Pity for the Python2.2 learner. Quite well realize that I am not saying anything that hasn't been said before on the issue. But disappointed to never have heard the counter argument from Guido - what put the issue over the top for him? If I was told that experinced programmers might appreciate this change for any possible reason - I'd be quiet as a mouse. Since I remain convinced that the single most important factor for Python's acceptance as an educational language is the growth of its acceptance as a professional language. It will be interesting to see where Guido chooses to draw the line on the thought process that lead him to his integer division conclusion. Which is the real issue - the integer division thing, stand-alone, not likely to be a deal breaker for anyone. Like to believe that there is more real world thinking than Guido chooses to share publicly. Alternatively, I'm baffled as hell. ART From guido@digicool.com Sun Jul 22 17:24:18 2001 From: guido@digicool.com (Guido van Rossum) Date: Sun, 22 Jul 2001 12:24:18 -0400 Subject: [Edu-sig] Re: PEP0238 lament Message-ID: <200107221624.MAA11625@cj20424-a.reston1.va.home.com> Arthur Siegel and I seem to be pushing each other's buttons constantly. I don't know why it is, but ever post of his feels like a flame or flamebait to me. I always feel that he attacks me as a person rather than attacking my arguments (usually because he claims that I haven't given any arguments). Try as I may, this makes it very hard, almost impossible for me to respond in a meaningful manner to Arthur's posts. I wonder what I've done to tick him off. I also wonder how come he is so good at ticking me off. The reason for wanting / to return a float (or at least a type that can represent close approximations of numbers like 0.75) has been discussed many times before. The summary of the argument in the PEP may not be complete, but I disagree with Arthur's assessment that integer division is not a problem -- the VPython folks have ample experience that it is. Because all Arthur does is tick me off, I'll leave it at this -- maybe someone else can explain it all to him. --Guido van Rossum (home page: http://www.python.org/~guido/) From pdx4d@teleport.com Sun Jul 22 19:20:27 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Sun, 22 Jul 2001 11:20:27 -0700 Subject: [Edu-sig] Re: PEP0238 lament In-Reply-To: <200107221624.MAA11625@cj20424-a.reston1.va.home.com> Message-ID: <4.2.0.58.20010722105006.00a44f00@pop3.norton.antivirus> I hadn't tuned in that PEP before, not being a Python guru nor deeply involved in the elaboration of the language, and so only an occasional visitor to the main Python newsgroup, let alone its many subsidiaries. In Arthur's defense, I'll say that in reading follow-up posts to Guido's on the Python list, I saw several skeptics with fairly cogent arguments. In Guido's defense, I'll say that none of these counter arguments seemed to personalize it to such an extent. In both Arthur's and Guido's defense, I'll say that they're both aware of psychological dynamics and are willing to talk about them in the open, even if smooth cofunctioning is not yet in the picture (and may never be -- who's to know?). In my own defense, I'll append that I respect for both Guido and Arthur and thank them both for enriching my life in various ways. I find it somewhat ironic that Arthur has been extolling the virtues of VPython to the extent of recommending it be included as part of the Standard Library (which would drag in Numeric as well), and that Guido sees this PEP as explicitly making the Python-VPython relationship a more integrated/seamless one -- and yet Arthur objects. Hah hah. Wearing my math teacher hat, I'll will add my two cents: The / symbol is problematic in that the decimal expansion of p/q is not necessarily terminal, and base 2 conversions make floating point representations of 2/3 different from the decimal expression we're taught in school. Booting Python 2.1: >>> 2./3 0.66666666666666663 There's a problem right there, for newbie/learner/newcomer kids. That's a different problem from 2/3 = 0, but it's still a problem that needs to be addressed out in the open (I'm not saying it isn't -- I'm exhorting teachers to understand the difference between decimals as conveyed in math text books, and the IEEE floating point specification, which is different).[1] Booting DrScheme 103: > (/ 2 3) 2/3 > 2/3 2/3 That's a different solution. The rational type (vs. float) is integrated into the language. In Python, you need to import a (non Standard Library) fraction class definition (e.g. Rat in yarn.py) to accomplish this, by means of objects. Scheme also includes GCD as a primitive. It's a different language. My own view is that no language can be all things to all people, so at some point you have to draw the line and say "this is what you can do in X, and if that's too onerous, given what you want to do, consider using Y instead -- don't expect X to be the best solution for every problem you tackle". Were I in charge, I might have preferred that / remain the way it is, until/unless a more Scheme-like inclusion of the rational number type (different from float) came along, which would happen when the "long" type melted away, and became part of "int" (seamless i.e. no difference from the user's point of view). This might have happened in 3.xx. I think it's somewhat premature to fiddle with / in 2.x. But I'm not in charge, and I can live with the change. On the whole, I think Guido's aesthetic sense has been excellent, and I give him very high grades. On the basis of this track record, I will defer to his judgement, all cogent arguments to the contrary noted and appreciated. In the meantime, I think I should exert greater effort to learn both Scheme and Eiffel. I'd also like to learn OCaml while I'm at it. Kirby From tim.one@home.com Sun Jul 22 19:22:21 2001 From: tim.one@home.com (Tim Peters) Date: Sun, 22 Jul 2001 14:22:21 -0400 Subject: [Edu-sig] RE: PEP0238 lament In-Reply-To: <00867F2E.N22121@rsmi.com> Message-ID: [Arthur_Siegel@rsmi.com] > ... > If I was told that experinced programmers might > appreciate this change for any possible reason - > I'd be quiet as a mouse. Not all experienced programmers agree. At the last Python Conference, I moderated a 40-some person group discussion on conceivable changes to Python's numeric model, not advocating but keeping the participants from killing each other . The meaning of integer division wasn't the focus, but naturally came up. By show of hands, about 3/4ths of the participants agreed that 3/4 should not return 0, but rather *something* x such that x*4 had a better chance of being confused with 3 than with 0. There was no consensus on exactly what 3/4 should return -- rational or HW float or decimal float were the most popular alternatives. It shouldn't be so hard to understand why. The current integer division loses information silently and without a trace. Combined with that Python is not a statically typed language, there's simply no telling what e.g. def velocity(distance, time): return distance / time will compute by inspection. This isn't about esoteric user overloading of "/", it's about ordinary arithmetic on builtin numeric types, and many experienced Python programmers have testified over the years to being burned in practice by stuff exactly that simple. I expect that either way is easy enough to *teach*, but I don't accept ease of teaching as a primary goal: I'm much keener on semantics that, once *learned*, are hard to forget or to stumble over. Even if such semantics are 100x harder to teach at first, fine by me: you spend the rest of your life living with the consequences. I wish the definition of continuity were easier to teach too, but that doesn't mean I'll settle for an easier definition that doesn't actually work . some-mice-are-surprised-when-thet-divide-up-the-cheese-and- cheese-mass-mysteriously-disappears-ly y'rs - tim From moshez@zadka.site.co.il Sun Jul 22 20:05:17 2001 From: moshez@zadka.site.co.il (Moshe Zadka) Date: Sun, 22 Jul 2001 22:05:17 +0300 Subject: [Edu-sig] RE: PEP0238 lament In-Reply-To: References: Message-ID: I'm the last person to avoid going off on a tangent. On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" wrote: > I wish the definition of continuity were > easier to teach too, but that doesn't mean I'll settle for an easier > definition that doesn't actually work . Here is one that is easier to teach, if you just reverse the order of teaching calculus and first-order logic and basic set theory. A function is continuous at c if, when embedding the world of Reals into a saturated model (or, say, 2^{Beth_omega} saturated, if you don't want to get into subtle assumptions), for every infinitesimal x, f(c+x)-f(c) is an infintesimal. Of course, you might think that teaching about saturation is hard -- well, it might be ;-) i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world- with-epsilons-and-deltas-ly y'rs, Z. -- gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6 Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE From tim.one@home.com Sun Jul 22 21:01:31 2001 From: tim.one@home.com (Tim Peters) Date: Sun, 22 Jul 2001 16:01:31 -0400 Subject: [Edu-sig] RE: PEP0238 lament In-Reply-To: Message-ID: [TIm] > I wish the definition of continuity were easier to teach too, but that > doesn't mean I'll settle for an easier definition that doesn't actually > work . [Moshe Zadka] > Here is one that is easier to teach, if you just reverse the order > of teaching calculus and first-order logic and basic set theory. > > A function is continuous at c if, when embedding the world of Reals > into a saturated model (or, say, 2^{Beth_omega} saturated, if you > don't want to get into subtle assumptions), for every infinitesimal x, > f(c+x)-f(c) is an infintesimal. > > Of course, you might think that teaching about saturation is hard -- > well, it might be ;-) Na, they always leave *some* of the foundations in intro calculus courses fuzzy. H. Jerome Keisler wrote a very good intro calculus text based on non-standard analysis, unfortunately now out of print. See http://www.math.wisc.edu/~keisler/books.html for publication details. He didn't try to explain the intricacies of model theory, he just spelled out "the rules" for working with infinitesimals and got on with it. Huge steaming masses of epsilon-delta proofs were conspicuous by absence, so he was able to get to "the interesting stuff" a lot quicker that way. A good feel for the flavor of the approach can be gotten by skipping to the end ("Part IV: Turning Calculus into Algebra") of http://online.sfsu.edu/~brian271/nsa.pdf and reading "~=" as "infinitely close to". > i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world- > with-epsilons-and-deltas-ly y'rs, Z. i-personally-blame-guido-for-letting-it-stand-ly y'rs - tim From pdx4d@teleport.com Mon Jul 23 06:35:39 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Sun, 22 Jul 2001 22:35:39 -0700 Subject: [Edu-sig] Other PEP talk In-Reply-To: References: Message-ID: <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> On a more upbeat note, I'm happy about other 2.2 PEPs I've been reading; about generators and iterators in particular. Those generators look like a way to get more lazy evaluation into the picture. Maybe that's why xrange is slowly going away. I think it's time to grab 2.2 and play with it. Kirby PS: I went off the read the Eiffel site, following my own self-exhortations to learn it, along with Ocaml and more Scheme. Alas, it's $2999 for the base package. That's a real deterrent to diving in just for the fun of it, in my case. There's a student version, but you have to submit documentation proving you're enrolled in some course. Well, I'm not. So I'm going to use the unexpended enthusiasm for learning Eiffel and plough it back into learning more Python. From pdx4d@teleport.com Mon Jul 23 07:42:37 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Sun, 22 Jul 2001 23:42:37 -0700 Subject: [Edu-sig] Example Generator (2.2a) In-Reply-To: <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> References: Message-ID: <4.2.0.58.20010722231455.00be7330@pop3.norton.antivirus> Here's some quick results of my play with the 2.2a generator feature. In the module below, primes() is defined not with 'return' but with keyword 'yield', signifying this is a special kind of function known as a generator. It preserves state between calls, picking up execution right after the yield. No need for threads. What play() returns, on being called, is a generator object: >>> from play import primes >>> p = primes() >>> p >>> p.__class__ >>> dir(p.__class__) ['__class__', '__getattr__', '__init__', '__iter__', '__new__', 'gi_frame', 'gi_running', 'next'] >>> p.__class__.__base__ Notice that a generator, like an iterator, implements a next() method. You can use next() explicitly to trigger successive yields, or implicitly by iterating over your generator object in a for-loop: >>> [p.next() for i in range(30)] [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113] >>> for i in p: print i, if i>100: break 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211 223 227 229 233 239 241 251 Notice how the 2nd use of p, in a for-loop, continues spitting out primes where the first list comprehension loop left off -- because p was not reinitialized in between, and therefore keeps going on up the list of primes. This is an example of lazy evaluation. We don't do the work to get a next prime until we need it, and we can treat the generator object as a source of primes. Note that even though primes() is maintaining state info between calls, you can't access its local variables as attributes as you might for a class, e.g. p.pr is not defined. This is why, if I want to make my growing list of primes available as a persistent list object, I needed to make it global. Kirby ============== """ play.py -- fun with generators """ from __future__ import generators def primes(): """ Generator: Yield next higher prime, starting at 2, accruing successive primes in global list pr """ global pr pr = [2] i,new = 1 while 1: i += 2 if new: yield pr[-1] new = 0 for t in pr: if t*t > i: # if t**2>candidate, we have a new prime pr.append(i) new = 1 break if i%t == 0: # test divide by primes so far, # move to next odd whenever remainder=0 break From tim.one@home.com Mon Jul 23 08:04:49 2001 From: tim.one@home.com (Tim Peters) Date: Mon, 23 Jul 2001 03:04:49 -0400 Subject: [Edu-sig] Example Generator (2.2a) In-Reply-To: <4.2.0.58.20010722231455.00be7330@pop3.norton.antivirus> Message-ID: [Kirby Urner] > Here's some quick results of my play with the 2.2a > generator feature. Note that there are many examples in Lib/test_generators.py too. I predict Kirby will enjoy some of them a lot . any-more-fun-than-this-and-it-would-be-illegal-ly y'rs - tim From pdx4d@teleport.com Mon Jul 23 08:21:03 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 23 Jul 2001 00:21:03 -0700 Subject: [Edu-sig] Example Iterator (2.2a) In-Reply-To: <4.2.0.58.20010722231455.00be7330@pop3.norton.antivirus> References: <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> Message-ID: <4.2.0.58.20010722235355.00bf1200@pop3.norton.antivirus> In this example, the Test class is designed to act as its own iterator, meaning it returns self in __iter__, and backs this up by implementing a next() method -- a requirement for iterators. This class accepts a phrase upon initialization, and iteration simply means returning the next character in the phrase. You stop iterating by throwing an exception. In a for-loop over the object, this simply terminates the loop, without an error message: >>> from play import Test >>> ot = Test("Able was I ere I saw Elba") >>> for k in ot: print k, A b l e w a s I e r e I s a w E l b a >>> But then if you try to force an iteration, you'll get a real exception. >>> ot.i 25 >>> ot.next() Traceback (most recent call last): File "", line 1, in ? ot.next() File "D:\PROGRAM FILES\PYTHON22\work\play.py", line 46, in next raise StopIteration,"Length of Phrase exceeded" StopIteration: Length of Phrase exceeded For-loops, though, simply return nothing, now that we're at the end of our rope. The value of ot.i will keep increasing in this example, even though the for-loop is mute (because of where the exception is raised in this class). >>> for k in ot: print k, >>> The __iter__ method supercedes using __getitem__ to support iteration in a for-loop. Using __getitem__ wasn't optimal, because your object might not support random access (as per PEP), i.e. you want to be able to iterate through a file-like object, but file[10] (dropping in on the 10th line) might not be something you want to implement (or even could if you wanted to). In other words, iteration and indexing aren't quite the same concept. Getting a next() element isn't the same as being able to jump right away to just *any* as in object[any int]. Notice that the iterator of ot is ot itself in this case: >>> iter(ot) >>> ot If, just for the heck of it, we were to return primes() in the __iter__ method, then we could still call ot.next() explicitly, but any implicit invocations of ot's iterator would invoke our primes generator function (a generator is able to work as an iterator, i.e. is like any user class which both supports next() and defines itself as an iterator). Looking at primes() again: >>> p >>> p.__iter__ >>> p.next And now looking at ot, an instantiation of Test wherein __iter__ has been redefined to return primes(): >>> ot = Test("Able was I ere I saw Elba") >>> ot.next() 'A' >>> ot.next() 'b' >>> for i in ot: print i, if i>100: break 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 Kirby More from play.py: ===================== class Test: def __init__(self,phrase): self.phrase = phrase self.i = -1 def __iter__(self): return self # return primes() -- alternative generator object def next(self): self.i += 1 if self.i>len(self.phrase)-1: raise StopIteration,"Length of Phrase exceeded" return self.phrase[self.i] From pdx4d@teleport.com Mon Jul 23 08:27:15 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 23 Jul 2001 00:27:15 -0700 Subject: [Edu-sig] Example Generator (2.2a) In-Reply-To: <4.2.0.58.20010722231455.00be7330@pop3.norton.antivirus> References: <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> Message-ID: <4.2.0.58.20010723002437.00bf7180@pop3.norton.antivirus> > > >>> [p.next() for i in range(30)] > [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, > 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, > 109, 113] > > >>> for i in p: > print i, > if i>100: break > > 127 131 137 139 149 151 157 163 167 173 179 181 191 193 > 197 199 211 223 227 229 233 239 241 251 Note, this was a mis-print. Cutting and pasting between IDLE and Eudora gets me into trouble sometimes. That was really 'if i>250: break' -- which is why we got those additional primes. Yes, thanks Tim, for reminding me to check the examples, written by pros who've had a lot of time to think about this stuff. Just doing a quick example and getting it to work, w/o checking those first, was also encouraging -- means even a non-pro like me can pick up the new toys and play with 'em, right out of the box (thanks to 'batteries included'). Kirby From tim.one@home.com Mon Jul 23 09:03:31 2001 From: tim.one@home.com (Tim Peters) Date: Mon, 23 Jul 2001 04:03:31 -0400 Subject: [Edu-sig] Other PEP talk In-Reply-To: <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> Message-ID: [Kirby Urner] > ... > PS: I went off the read the Eiffel site, following my > own self-exhortations to learn it, along with Ocaml and > more Scheme. Alas, it's $2999 for the base package. > That's a real deterrent to diving in just for the fun > of it, in my case. There's a student version, but you > have to submit documentation proving you're enrolled in > some course. Well, I'm not. So I'm going to use the > unexpended enthusiasm for learning Eiffel and plough it > back into learning more Python. While I have to agree with your sensible conclusion, you needn't give up on Eiffel *that* quickly. The FSF also produces an Eiffel compiler, and for free; see http://smalleiffel.loria.fr/ This is a healthy and active project; the latest release was just last week. In ISE's "defense", I hope they get filthy rich selling Eiffel! Then maybe they can afford to support Python development too . From pdx4d@teleport.com Mon Jul 23 17:40:19 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 23 Jul 2001 09:40:19 -0700 Subject: [Edu-sig] Another Iterator Example (2.2a) In-Reply-To: <4.2.0.58.20010722235355.00bf1200@pop3.norton.antivirus> References: <4.2.0.58.20010722231455.00be7330@pop3.norton.antivirus> <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> Message-ID: <4.2.0.58.20010723092955.00be8d20@pop3.norton.antivirus> In the example below, we approximate the 2nd root of a number using Newton's method. Each call to the .next() method of our generator function gives a next approximation, until the next guess is no different from the last one, at which point we return (warning: this is *not* a good test on which to stop iteration, as the guesses may oscillate between two values -- better is to stop when the difference is under some threshold). To return from a generator is to end its effective life span, although it sticks around to remind you it's dead. Further calls to it throw a StopIteration exception: >>> from play import * >>> s = sqrt(2) >>> s.next() 1.0 >>> s.next() 1.5 >>> s.next() 1.4166666666666667 >>> s.next() 1.4142156862745099 >>> s.next() 1.4142135623746899 >>> s.next() 1.4142135623730949 >>> s.next() Traceback (most recent call last): File "", line 1, in ? s.next() StopIteration On the other hand, as we learned about iterators in general in the last example, the for-loop use simply ends, without throwing an exception, when the terminal condition is reached (in this case, a return). >>> s = sqrt(2) >>> for i in s: print "%r" % i 1.0 1.5 1.4166666666666667 1.4142156862745099 1.4142135623746899 1.4142135623730949 You can restart the generator simply by reinitializing it: >>> s = sqrt(2) >>> [i for i in s] [1.0, 1.5, 1.4166666666666667, 1.4142156862745099, 1.4142135623746899, 1.4142135623730949] Source: from __future__ import generators def sqrt(target): guess = 1.0 # initialize to 1 while 1: newguess = (guess**2 + target)/(2*guess) yield guess if newguess==guess: return guess = newguess From Gareth.McCaughan@pobox.com Mon Jul 23 21:15:34 2001 From: Gareth.McCaughan@pobox.com (Gareth McCaughan) Date: Mon, 23 Jul 2001 21:15:34 +0100 Subject: [Edu-sig] Re: PEP0238 lament In-Reply-To: References: Message-ID: > Here is one that is easier to teach, if you just reverse the order > of teaching calculus and first-order logic and basic set theory. > > A function is continuous at c if, when embedding the world of Reals > into a saturated model (or, say, 2^{Beth_omega} saturated, if you > don't want to get into subtle assumptions), for every infinitesimal x, > f(c+x)-f(c) is an infintesimal. Ahhhh, it's good to see another right-thinking person on c.l.py ... Perhaps if Christian Tismer finds that Stackless is too easy he might be persuaded to maintain Nonstandard Python. :-) -- Gareth McCaughan Gareth.McCaughan@pobox.com .sig under construc From paulp@ActiveState.com Tue Jul 24 00:10:10 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Mon, 23 Jul 2001 16:10:10 -0700 Subject: [Edu-sig] Re: PEP0238 lament References: <00867F2E.N22121@rsmi.com> Message-ID: <3B5CAED2.80B9CF3C@ActiveState.com> This issue is constantly presented as some sort of dichotomy between "regular" programmers" and newbies. But really it is more of a dichotomy between those originally trained on typed languages and those on dynamically typed languages. The other languages in the Python category (Perl, Ruby, JavaScript, ...) all make a different choice for division and the choice is uncontroversial. Python is the only one of the languages that has a constant battle on the issue. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From tim@digicool.com Tue Jul 24 00:27:50 2001 From: tim@digicool.com (Tim Peters) Date: Mon, 23 Jul 2001 19:27:50 -0400 Subject: [Edu-sig] RE: PEP0238 lament In-Reply-To: <3B5CAED2.80B9CF3C@ActiveState.com> Message-ID: [Paul Prescod] > This issue is constantly presented as some sort of dichotomy between > "regular" programmers" and newbies. But really it is more of a > dichotomy between those originally trained on typed languages and > those on dynamically typed languages. Excellent point, Paul! The newbies get dumped on because they're the only ones impudent enough to complain about it -- Guido hasn't crushed their spirits yet . > The other languages in the Python category (Perl, Ruby, JavaScript, > ...) all make a different choice for division and the choice is > uncontroversial. Python is the only one of the languages that has a > constant battle on the issue. It suggests Python may want to leap to what Perl eventually added: a directive akin to Perl's "use integer;". In Python's case I really don't see any other way to prevent large scale code breakage as the years roll by. From BPettersen@NAREX.com Tue Jul 24 00:30:04 2001 From: BPettersen@NAREX.com (Bjorn Pettersen) Date: Mon, 23 Jul 2001 17:30:04 -0600 Subject: [Edu-sig] RE: PEP0238 lament Message-ID: <6957F6A694B49A4096F7CFD0D900042F27D575@admin56.narex.com> > From: Paul Prescod [mailto:paulp@ActiveState.com] >=20 > This issue is constantly presented as some sort of dichotomy between > "regular" programmers" and newbies. But really it is more of a=20 > dichotomy between those originally trained on typed languages and=20 > those on dynamically typed languages. >=20 > The other languages in the Python category (Perl, Ruby,=20 > JavaScript, ...) > all make a different choice for division and the choice is > uncontroversial. Python is the only one of the languages that has a > constant battle on the issue. Ruby seems to be quite in line with (current) Python: irb(main):001:0> puts 1/2 0 nil irb(main):002:0> puts 1.0/2 0.5 nil irb(main):003:0> -- bjorn From pdx4d@teleport.com Tue Jul 24 00:33:31 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 23 Jul 2001 16:33:31 -0700 Subject: [Edu-sig] Once more around the block (generators) In-Reply-To: <4.2.0.58.20010723002437.00bf7180@pop3.norton.antivirus> References: <4.2.0.58.20010722231455.00be7330@pop3.norton.antivirus> <4.2.0.58.20010722222941.00b8ddb0@pop3.norton.antivirus> Message-ID: <4.2.0.58.20010723140609.00be5100@pop3.norton.antivirus> The iterator type and generator classes must support next() -- you must be able to return the next element. Whether an iterator class also supports __getitem__ or previous() or other such methods is up to the programmer. Below, I turn what had been the primes() generator function into the Primes class. The generator becomes a private, internal class method, and is what the class returns when asked for an iterator (__iter__). Calls to next() either trigger this iterator (stored in self.gen), or return values from territory already covered. Given Primes is a class, you'll be begetting one or more instantiated objects. Each keeps track of an internal pointer, specific to the object, in self.current. obj.previous() is relative to where the pointer is, currently. obj[n] resets the pointer to n (perhaps triggering next() a number of times in the process), while obj.last() sets the pointer to the highest value the pointer has ever reached. But in the background, all instantiations of Primes share the same class variable Primes.pr (a growing list of primes). This means that if one object computes the 10,000th prime, then all objects have access to the result i.e. don't need to recompute it. Having the different instantiations share a common Primes.pr while maintaining their own specific pointers proved an interesting challenge. In action: >>> from play import * >>> pr1 = Primes() >>> pr1[10] 31 >>> pr2 = Primes() >>> pr2.pr [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31] >>> pr2.last() 2 >>> pr2.skip(4) 11 >>> pr2.current 4 >>> pr2.last() 11 >>> pr2[15] 53 >>> pr2.pr [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53] >>> pr2.last() 53 >>> pr1.pr [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53] >>> pr1.last() 31 >>> pr1.skip(25) 127 >>> pr1.pr [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127] >>> pr2.skip(1) 37 >>> pr2.last() 37 >>> pr2.first() 2 Source appended. Kirby ========== from __future__ import generators class Primes: pr = [2] def __init__(self): self.gen = self.__generator() self.current = 0 self.max = 0 def __iter__(self): return self def next(self): self.current += 1 self.max = max(self.max,self.current) if self.current > len(Primes.pr)-1: return self.gen.next() else: return Primes.pr[self.current] def previous(self): self.current -= 1 return self.pr[self.current] def first(self): self.current = 0 return Primes.pr[self.current] def last(self): self.current = self.max return Primes.pr[self.current] def skip(self,n): # pointer must be >= 0 return self.__getitem__(max(0,self.current + n)) def __getitem__(self,n): if n<0: raise ValueError,"Out of range" if n > len(Primes.pr)-1: self.current = self.max while n > self.current: self.next() else: self.current = n self.max = max(self.max,self.current) return Primes.pr[self.current] def __generator(self): """ Iterator: Yield next higher prime, accruing successive primes in class variable pr """ i = Primes.pr[-1] if i==2: i -= 1 new = 0 while 1: try: i += 2 except OverflowError: i += 2L if new: yield Primes.pr[-1] new = 0 for t in Primes.pr: if t*t > i: # if t**2>candidate, we have a new prime Primes.pr.append(i) new = 1 break if i%t == 0: # test divide by primes so far, # move to next odd whenever remainder=0 break From paulp@ActiveState.com Tue Jul 24 00:54:15 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Mon, 23 Jul 2001 16:54:15 -0700 Subject: [Edu-sig] Re: PEP0238 lament References: <00867F2E.N22121@rsmi.com> <3B5CAED2.80B9CF3C@ActiveState.com> Message-ID: <3B5CB927.1D60A7DA@ActiveState.com> Paul Prescod wrote: > >... > > The other languages in the Python category (Perl, Ruby, JavaScript, ...) I'm sorry, it turns out that I was wrong about Ruby. By default Ruby uses closed-integer division. I presumed incorrectly that it followed Perl. In Ruby you could probably change this behaviour using overloading but this is probably ill-advised because it would probably change the behaviour of libraries. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook From pdx4d@teleport.com Tue Jul 24 01:44:54 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Mon, 23 Jul 2001 17:44:54 -0700 Subject: [Edu-sig] Computer science without all that "heavy math" stuff...? In-Reply-To: <4.2.0.58.20010720080844.00be38a0@pop3.norton.antivirus> References: Message-ID: <4.2.0.58.20010723174208.00bf0340@pop3.norton.antivirus> > >Beyond this, I'm a big fan of field experience mixed with >coursework (a.k.a. work-study). As the not-for-profit sector >gets higher tech, it gives para-professionals opportunities >to hone skills in more volunteer-like capacities, perhaps >apprenticing under those with more experience. This is how >many have used their military experience, but I'm also >talking civilian sector opportunities -- e.g. learn some >IS skills in the Peace Corps, in Burundi. > >Kirby Along these lines, I should mention 'Geeks in Ghana' by Ken J. Habeeb in the most recent InfoWrold (07.23.01), pg. 42. "In a small West African country, IT pros from Europe and the United States donate time and talent to local businesses." You can read all about it here: http://iwsun4.infoworld.com/articles/ca/xml/01/07/23/010723caghana.xml Kirby From ajs@ix.netcom.com Tue Jul 24 02:08:19 2001 From: ajs@ix.netcom.com (Arthur Siegel) Date: Mon, 23 Jul 2001 21:08:19 -0400 Subject: [Edu-sig] Re: PEP0238 lament Message-ID: <000001c113e2$8cf52fe0$a9e1fea9@carol> >Well, I'll see what I can do. In the language there are (at least) >two distinct things we might want to do when "dividing" A and B: > (1) split A up into B parts > (2) find how many B's fit in an A etc... The well intentioned response I think only points out the problem more. You don't seem to understand that my point is that, within reason, I do in fact understand all this fairly well. Anyone else of normal intelligence should be able to also. My further point is that there is a lot about programming that I do find difficult. The difficult parts. Which is why I keep feeling the techies among you have lost touch with common sense. Almost comically. The easy stuff is easy, the hard stuff is hard. It's not that difficult to separate which is which. Which is why I am always amazed at what gets reported - and taken seriously - as significant. Will I have any problem with // and / - using them appropriately Doubt it. Can I handle case sensitivity any way you give it to me. Cake. Why is two years of discussion going on as if someone like myself is not fully representative. I simply have no reason to believe I am not. And will scrutinize carefully any evidence which contends otherwise. Should major design decisions for a professional language be made on anecdotal reports from ???????? sources without a hard look at their context and meaning. Not in my opinion. Do I believe the change is a significant enhancement on behalf of the newbie. Not in the least. Will Python be a better language after it is done. I don't have a good basis to disagree with that assertion. And none of these statements seem a bit contradictory to me. >A good example of (1) is float division, and the cannonical example >of (2) is "int division", aka "div". These are DIFFERENT THINGS. >For instance, if you are implementing a sort algorithm, you may >well want (2) in a place where (1) will never do! On the other >hand, if your program is performing CAD drawings, then (1) is >probably the meaning you need. Note that (2) often makes most sense >with integers (especially since it always gives out an integer), >while (1) may make sense with floats, rationals, fixed-position >decimals, as well as various other numerical types. From ajs@ix.netcom.com Tue Jul 24 02:53:49 2001 From: ajs@ix.netcom.com (Arthur Siegel) Date: Mon, 23 Jul 2001 21:53:49 -0400 Subject: [Edu-sig] Re: PEP0238 lament Message-ID: <001301c113e3$7c039cc0$a9e1fea9@carol> Kirby writes - >In the meantime, I think I should exert greater effort >to learn both Scheme and Eiffel. I'd also like to learn >OCaml while I'm at it. Travel broadens, no doubt. ART From Kristen_Blanco@prenhall.com Tue Jul 24 14:40:49 2001 From: Kristen_Blanco@prenhall.com (Kristen_Blanco@prenhall.com) Date: 24 Jul 2001 09:40:49 -0400 Subject: [Edu-sig] Seeking Technical reviewers for Python Message-ID: <"/GUID:QTsigeTSA1RGZOABgCI2PYQ*/G=Kristen/S=Blanco/OU=exchange/O=pearsontc/PRMD=pearson/ADMD=telemail/C=us/"@MHS> am writing from Prentice Hall publishing and I am seeking reviewers for an upcoming publication. We are one of the largest college textbook publishers in the US. We are publishing a book entitled "Python How to Program" by Harvey and Paul Deitel. They are premier programming language authors, with the best-selling C++ and Java books in the college market place. More information on their suite of publications can be found here: http://www.prenhall.com/deitel We are presently seeking qualified technical reviewers to verify that the Deitels' coverage of Python in their forthcoming book is accurate. In return, we are offering a token honorarium. Might you be willing to participate? If not, could you perhaps suggest a colleague? If you are interested, or have any questions, please contact my colleague, Crissy Statuto, at Crissy_Statuto@prenhall.com Thank you in advance for your assistance and consideration. Sincerely, Crissy Statuto Crissy Statuto Project Manager, Computer Science Prentice Hall One Lake Street- #3F54 Upper Saddle River, NJ 07458 Tel: 201-236-6695 Fax: 201-236-7170 Email: crissy_statuto@prenhall.com From urnerk@qwest.net Thu Jul 26 03:27:12 2001 From: urnerk@qwest.net (Kirby Urner) Date: Wed, 25 Jul 2001 19:27:12 -0700 Subject: [Edu-sig] More spillover re the division PEP In-Reply-To: References: Message-ID: <4.2.0.58.20010725192603.00941e00@pop3.norton.antivirus> From: Kirby Urner Newsgroups: comp.lang.python Subject: Nostalgia for the present (re the infamous PEP) Date: Wed, 25 Jul 2001 10:10:27 -0700 I tell ya, given all the uproar over // vs /, I'm already nostalgic for the good ol' days (these are them), when / left it up to its arguments to determine the type of the result. In so doing, it followed the same type conventions as the other arithmetic operators: Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> type(1+1) >>> type(1+2.) >>> type(1*2) >>> type(1*2.) >>> type(1/2) >>> type(1/2.) But now we're gonna have: >>> type(1/2) The programmer doesn't have to do any casting, as type conversion when returning a result is automatic. def velocity(miles,hour): return float(miles)/hour In the new regime, / is guarenteed to return a float, and // is guarenteed to return and int, no matter what the numeric args. This puts / in a new category among the arithmetic operators: the operator itself ensures type of result, not the args. But that's because / *is* special in some ways: + - and * are all closed in Z (integers), but the integers form a ring, not a group, with respect to + and *, such that the multiplicative inverse of j -- i.e. 1/j or j**(-1) -- is not in Z unless j=1. This is what's driving / to be coercive, and to differentiate from //. My own view is there's a lot of rationale for either way of doing it, with the fact of the initial design choice weighing heavily on the side of keeping it the way it is. I prefer that newbies learn that type(int/int)==int and that pro programmers sometimes "get burned", and that Guido not be apologetic or remorseful for this initial design choice -- nor for making Python case-sensitive (a perfectly reasonable decision as well -- it's gotta be one way or the other, and there's plenty to say in favor of either). To take a page from our favorite giant: It's not a wart (bug), it's a feature. Kirby From kevino@tulane.edu Thu Jul 26 05:58:43 2001 From: kevino@tulane.edu (Kevin Ollivier) Date: Thu, 26 Jul 2001 00:58:43 -0400 Subject: [Edu-sig] More spillover re the division PEP References: <4.2.0.58.20010725192603.00941e00@pop3.norton.antivirus> Message-ID: <006001c1158f$a5d08f60$6401a8c0@cox.rr.com> ----- Original Message ----- From: "Kirby Urner" To: Sent: Wednesday, July 25, 2001 10:27 PM Subject: [Edu-sig] More spillover re the division PEP > From: Kirby Urner > Newsgroups: comp.lang.python > Subject: Nostalgia for the present (re the infamous PEP) > Date: Wed, 25 Jul 2001 10:10:27 -0700 > > > I tell ya, given all the uproar over // vs /, I'm already nostalgic for the > good ol' days (these are them), when / left > it up to its arguments to determine the type of the result. > In so doing, it followed the same type conventions as the > other arithmetic operators: I guess I saw things differently up until now. I always thought Python, by design, performed the conversion whenever the conversion was needed. This ensures that when you run an arithmetic operation, you get the result - not a type error or lost data. I would bet this reasoning accounts for why many newbies stumble on the division issue. I now realize that is not how Python works, but why shouldn't it work that way? I don't mean to sound as if I'm complaining, I would just like to know why it works the way it does. > My own view is there's a lot of rationale for either way of > doing it, with the fact of the initial design choice weighing > heavily on the side of keeping it the way it is. I prefer that > newbies learn that type(int/int)==int and that pro programmers > sometimes "get burned", and that Guido not be apologetic > or remorseful for this initial design choice -- nor for making > Python case-sensitive (a perfectly reasonable decision as > well -- it's gotta be one way or the other, and there's plenty > to say in favor of either). May I ask why you prefer this? What is the benefit for the Python programmer to use this format? I really think the change should be considered, especially since it is a stumbling block for new learners. (I imagine it is especially frustrating to hobbyists learning it on their own time, who don't have a professor to consult.) I think also that demand for this feature to be changed will increase as more and more people start using Python, so it may be good to address it now. I think the simple, deciding factor on the issue is whether or not most programs (and progammers) need or expect an equation like "1/2" to evaluate to 0. If 0 is the "correct answer" in a majority of situations, then the current behavior should stay. However, if 0.5 is the "correct answer" in a majority of situations and many programmers are thus writing "division functions" to type-check and convert arguments to ensure this answer is returned, then the behavior needs to be changed. I personally feel it should be changed as the PEP at least ensures that (for most purposes) no one has to write their own division function to ensure they get the answer they expect. (I actually like Tim Peters' idea of the "use integer" directive.) As you say, there are good rationales for both approaches, and I don't think it is a matter of "right or wrong". That is why I feel we shouldn't really focus on the reasoning for both approaches - they are both quite sound. Instead, I think we should focus on how Python can be most useful to people. We should keep the people being "burned" to a bare minimum, and I doubt we can ensure that all the Python training out there sufficiently addresses the division issue. > To take a page from our favorite giant: It's not a wart (bug), > it's a feature. Ah, but beauty is in the eye of the beholder. I doubt many of us would describe our experiences with the software giant as 'full-featured'. =) Kevin From urnerk@qwest.net Thu Jul 26 06:44:14 2001 From: urnerk@qwest.net (Kirby Urner) Date: Wed, 25 Jul 2001 22:44:14 -0700 Subject: [Edu-sig] More spillover re the division PEP In-Reply-To: <006001c1158f$a5d08f60$6401a8c0@cox.rr.com> References: <4.2.0.58.20010725192603.00941e00@pop3.norton.antivirus> Message-ID: <4.2.0.58.20010725222632.00beadf0@pop3.norton.antivirus> > >I think the simple, deciding factor on the issue is whether or not most >programs (and progammers) need or expect an equation like "1/2" to >evaluate to 0. If 0 is the "correct answer" in a majority of situations, >then the current behavior should stay. However, if 0.5 is the "correct >answer" in a majority of situations and many programmers are thus writing >"division >functions" to type-check and convert arguments to ensure this answer is >returned, then the behavior needs to be changed. <> >Kevin Well, I think you're in the majority, plus the BDFL agrees, so by 3.0 looks like we'll be having / do type conversion as needed. Note that you don't have to do type checking before converting, if you know it's a number -- if you don't know, i.e. it might be a string, then you have to type check anyway, or catch the exception -- i.e. float(a)/b is sufficient to return a float result, and is self- documenting as to programmer intent. Another idiom is (x*1.)/y -- you don't type check before executing (if x was already a float, so what). If you're going to be using these variables a few times, coerce 'em up top, like when declaring variable types in other languages e.g. # int [float] -> float x *= 1. y *= 1. ... r = x/y 1/2 = 0.5 is the behavior most expect from their calculators, where int-type division ala Python doesn't occur (you might get fractions in p/q format, but those are 'rationals' not 'floats'). I probably shouldn't be so nostalgic for the status quo. After all, I do a lot of coding in Xbase (?), e.g. VFP (?) and that's a weakly typed interpreted language like Python, and is case insensitive (as Guido has proposed for Python, but given up on) and it evals 1/2 the way Python is going to soon (i.e. 1/2 = .5). It'll be very familiar territory (same for a lot of other programmers, coming from other languages where this is the norm). Kirby From kevino@tulane.edu Thu Jul 26 16:25:02 2001 From: kevino@tulane.edu (Kevin Ollivier) Date: Thu, 26 Jul 2001 11:25:02 -0400 Subject: [Edu-sig] More spillover re the division PEP References: <4.2.0.58.20010725192603.00941e00@pop3.norton.antivirus> <4.2.0.58.20010725222632.00beadf0@pop3.norton.antivirus> Message-ID: <00af01c115e7$241b92a0$6401a8c0@cox.rr.com> <> > I probably shouldn't be so nostalgic for the status quo. > After all, I do a lot of coding in Xbase (?), e.g. VFP (?) > and that's a weakly typed interpreted language like Python, > and is case insensitive (as Guido has proposed for Python, > but given up on) and it evals 1/2 the way Python is going > to soon (i.e. 1/2 = .5). It'll be very familiar territory > (same for a lot of other programmers, coming from other > languages where this is the norm). >Kirby Actually, I liked the comment Tim Peters made about using directives (what about "use integer" and "use case"?) There will still need to be a default behavior, but it does let everyone make Python work the way they want it to. And as Tim said, it will be much easier to ensure that Python scripts are compatible with the latest version of Python. In fact, if you were to do something like put it in comments (#use integer) then the code would actually run correctly in all versions of Python. Nothing wrong with being nostalgic, I actually understand your point of view. After all, I find myself constantly saying "I wish language X worked like Python did." I started prgoramming with VB (hobbyist), which has led me to a great appreciation of the way Python does things! =) Kevin From Arthur_Siegel@rsmi.com Thu Jul 26 17:55:06 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Thu, 26 Jul 2001 11:55:06 -0500 Subject: [Edu-sig] re: More spillover re the division PEP Message-ID: <008843E4.N22121@rsmi.com> Kevin writes - >I guess I saw things differently up until now. I always thought Python, by >design, performed the conversion whenever the conversion was needed. This >ensures that when you run an arithmetic operation, you get the result - not >a type error or lost data. I would bet this reasoning accounts for why many >newbies stumble on the division issue. I now realize that is not how Python >works, but why shouldn't it work that way? I don't mean to sound as if I'm >complaining, I would just like to know why it works the way it does. To me this is all about the need for precision in a whole different sense - precision in language. Keep trying to ask - what is a "newbie" and what is the "Programming" in CP4E supposed to mean., "3.1.1 Numbers" of Guido and Fred' tutorial which ships with Python covers the issue of the division operator. My recollection of my true newbie mindset - let me know clearly what the rules are and I will try to play by them. That is my work - my contribution to the learning effort. Certainly Guido and Fed made theirs. The tutorial makes the rules clear. Have I made typos - 3/4 when I meant 3. / 4 - yes. Did I have any significant conceptual problems about what was going on. No. It is actually the hidden bug argument that I find most compelling. But it has nothing to do with newbie status. Absolutely nothing. Should a language be desgined to minimize the possiblity of a hidden unintended result from a missing ".". I guess probably it should, to the extent possible. Obviously this argument is most compelling where we are talking about significant applications. So, by definition, not a newbie issue. Should the language be designed to prevent conceptual errors by folks who haven't made it to Chapter 3 of its introductory tutorial. For reasons that I can't even explain to myself, the argument that it should - if and to the extent that argument has been advanced in these discussions - makes me nuts. A more interesting argument is to what extent we should concern ourselves about those with an interest in learning to program who who read Chapter 3 carefully, and can't follow it - don't have the background to make any sense of it. That's certainly worth talking about. But first we need to have some evidence that such a population exists, which we do not. Or that, if such a population does exist, programming language design is a reasonable arena in which to expect to be able to offer them help[. ART From pdx4d@teleport.com Thu Jul 26 17:22:32 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Thu, 26 Jul 2001 09:22:32 -0700 Subject: [Edu-sig] re: More spillover re the division PEP In-Reply-To: <008843E4.N22121@rsmi.com> Message-ID: <4.2.0.58.20010726090436.00b959d0@pop3.norton.antivirus> I agree with Art that this really shouldn't have much to do with "newbies" (how to define? -- new to Python in particular, or to programming in general; I suppose the latter). Forcing type coercian looks a bit easier when you write 3./4 vs p/q, as the former show their types by inspection. It's p/q that's more problematic because we don't know what it will do until we either (a) type check or (b) coerce, on the assumption that p and q are at least int, float or long. Suppose p = long('2847509247509234750924752309') and q = 5. Then p/q returns 569501849501846950184950461L whereas float(p)/q returns 5.6950184950184698e+026. We know that the former is how many times 5 divides evenly into p; there might still be a remainder (and there is: 4). Using // in the code tells other programmers that division of the former kind is expected (tossing out the remainder, keeping results integer). / says the result will be float. You don't need to look elsewhere in the code to try to figure out if p and q are both ints. Given this is code you didn't write, you maybe don't get to force a type coercian either (who said you could change what's written? -- maybe this is a commercial app and you job is to understand but NOT tweak). So you're left trying to discover the secret identities of p and q, if you want to know how this operator will behave. In a weakly typed language, that's not easy. Maybe the coder has some p *= 1. nearby, but who's to enforce such an idiom? Now of course we have overdetermination in + as well, i.e. a + b might concatenate, vs. add numbers. But it's somewhat easier to track when a variable is being treated as an str vs. some kind of number, than it is to be sleuthing the diff between float, int and long usages. So I can see the argument for making the return value explicitly typed thanks to what operator is used (/ or //). I don't need to think about newbies. I think about pro programmers studying code they didn't write and trying to figure it out. Kirby >>> float() 2.847509247509235e+027 >>> float(long('2847509247509234750924752309'))/5 >>> long('2847509247509234750924752309')/5 >>> divmod(long('2847509247509234750924752309'),5) (569501849501846950184950461L, 4L) From Arthur_Siegel@rsmi.com Thu Jul 26 19:32:40 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Thu, 26 Jul 2001 13:32:40 -0500 Subject: [Edu-sig] re: More spillover re the division PEP Message-ID: <00885842.N22121@rsmi.com> Kirby writes - >So I can see the argument for making the return value >explicitly typed thanks to what operator is used (/ or //). >I don't need to think about newbies. I think about pro >programmers studying code they didn't write and trying to >figure it out. So we have a consensus I think. True it is annoying to have to share a language with a bunch of pros. And the change in the division operator status might represent a small sacrifice to the pedagogical value of the language. But all in all, community spirit being what it is - we learners,novices, and educators graciously accept to sacrifice on their behalf. Should we let them know? ART From Arthur_Siegel@rsmi.com Thu Jul 26 20:13:40 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Thu, 26 Jul 2001 14:13:40 -0500 Subject: [Edu-sig] re: More spillover re the division PEP Message-ID: <00885843.N22121@rsmi.com> Kirby writes - >I agree with Art that this really shouldn't have much to >do with "newbies" (how to define? -- new to Python in >particular, or to programming in general; I suppose the >latter). But there is another category. Take my PyGeo, for example. At the top level, there is a very limited API exposed to Python scripting. The point is to study geometry, using that API, via Python. In the context of a geometry class, no transfer of programming knowledge intended. Write this, expect that to appear. It is my job as the application writer to aniticipate my users ability to work within the API I define. Python is great, but not ideal, in that role. But I think it would be nuts for anything of substance to be sacrificed to make it more perfect in that limited role. My application. My problem. Obviously since I have written (in part) to it, I consider the API scripter to be a legitimate constituency for Python and for Python in education. But it is outside the realm of the P in CP4E - by my definition. Not a novice, not a newbie - I propose a new category for another legitimate constituency - the "scripter". Tremendous confusion has been caused, in my opinion, by not being explicit about defining constituencies. ART From Brent.Burley@disney.com Thu Jul 26 19:38:40 2001 From: Brent.Burley@disney.com (Brent Burley) Date: Thu, 26 Jul 2001 11:38:40 -0700 Subject: [Edu-sig] PEP 238 - non-integer division Message-ID: <3B6063B0.AA53BAFB@fa.disney.com> Sorry for jumping in so late. I'd like to argue in opposition to 238. 1) pep 238 introduces significant backwards incompatibility. Existing code may work differently, or may even fail. Consider x/2&1. If x/2 is automatically promoted to a float as in pep 238, you'll get an error: "TypeError: unsupported operand type(s) for &". If you want to write code that will work now and in the future, you'll need to do: int(x/2)&1 which is tedious and error prone. 2) pep 238 breaks consistency with C, C++ and Java. Considering that, like C++ and Java, Python incorporated most of C's operators including all of the integer operators (<<, &, |, ^, etc.), having one operator behave differently will impede transfer of knowledge to/from those languages. This is especially troublesome since python is so often used in a hybrid C or Java environment. 3) pep 238 makes the language inconsistent with itself. None of the other operators return a float for integer arguments. In general terms, there's an automatic promotion from int to long int to float. 4) The rationale given for pep 238 is that 1/2==0 is a "hump in the learning curve" and "manages to trip up new programmers regularly." This may be the case, but it's not clear that pep 238 reduces the learning curve. I think it just moves the hump a little farther down the road and possibly makes it bigger at the same time. Consider trying to teach type promotion. If you now have to include "except for '/'" in every explanation, it will be a much harder concept to grasp and apply. As long as Python treats integers differently than other numbers (e.g. doesn't allow the use of certain operators like '&'), users will need to understand that there is a difference between integers and floats and what the ramifications are. -- Comparisons with Perl have been mentioned. In Perl 1/2==0.5. However, what Perl does is _radically_ different from what is being proposed. Perl operates on "numbers" which in most cases behave like floats. Internally, ints are used where possible for efficiency, but as far as I can tell, there's no way to determine whether an integer or a float (with an integer value) is being stored, and it doesn't matter. Perl just jumps back and forth between integer and float (and even string) automatically, always trying to "do the right thing." Perl _almost_ always does what you want. However, it often feels a little bit too magical, that it's hard to develop an intuition for what's going on under the hood. If Python could be made to work like Perl and work on "numbers" without making users worry about ints vs floats, this would seem to be a much better approach. However, it seems like much too fundamental a change to be making at this stage of the development of the language. Brent From pdx4d@teleport.com Thu Jul 26 19:59:33 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Thu, 26 Jul 2001 11:59:33 -0700 Subject: [Edu-sig] PEP 238 - non-integer division In-Reply-To: <3B6063B0.AA53BAFB@fa.disney.com> Message-ID: <4.2.0.58.20010726115216.00bf1440@pop3.norton.antivirus> At 11:38 AM 7/26/2001 -0700, Brent Burley wrote: >Sorry for jumping in so late. I'd like to argue in opposition to 238. Yes, your points are being represented vociferously on comp.lang.python. The thing about / is it's exceptional in mathematics itself. *, + and - are closed for integers, but / takes you out into the rationals (as per how these keys work on any calculator -- except we use floats). a/b will be essentially equivalent to float(a)/b a//b will be divmod(a,b)[0] It's true that code will break, but you have the option to specify which version of Python you app needs. If the app is being actively maintained, then you can keep abreast the latest version. My understanding is the change will be finalized in 3.x, which was slated to be not-so-backward-compatible in any case. Kirby From pdx4d@teleport.com Thu Jul 26 20:11:34 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Thu, 26 Jul 2001 12:11:34 -0700 Subject: [Edu-sig] re: More spillover re the division PEP In-Reply-To: <00885843.N22121@rsmi.com> Message-ID: <4.2.0.58.20010726120107.00bf2620@pop3.norton.antivirus> > >Tremendous confusion has been caused, in my opinion, by not >being explicit about defining constituencies. > >ART If PyGeo is distributed open source, then there's always the implied invitation to (a) study the code and (b) tweak it. You never know when your scripters will be doing this, out of curiosity if nothing else. If exporting an API in the form of a scripting language, you can write a layer of code to parse student input, and have your symbols behave any way you choose. "/" could have whatever behavior you like, as you're in a position to interpret a mini-language of your own devising. In this sense, CPython is an API to C (and Jython to Java). But then C is an API to assembler and ultimately the computer chip's instruction set. In any case, these are all just hats. I'm a newbie with respect to language A, casual user of B, non-user of C, pro with D. Always a newbie, always a pro -- that's life in the big city.(*) Kirby (*) you might say true newbies don't know any programming at all, but even infants are starting to control their environments. We're all programmers by birth. CP4E is just another name for using language of any kind, the C in CP4E being the predictable, machine-like nature of the universe itself. From pdx4d@teleport.com Thu Jul 26 20:24:35 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Thu, 26 Jul 2001 12:24:35 -0700 Subject: [Edu-sig] PEP 238 - non-integer division In-Reply-To: <3B6063B0.AA53BAFB@fa.disney.com> Message-ID: <4.2.0.58.20010726121756.00bf8100@pop3.norton.antivirus> > >languages. This is especially troublesome since python is so often used >in a hybrid C or Java environment. To argue the other side, C and Java both require you to explicity declare the type of your variable, and the rules of coercian tell you, in the code itself, when a change is happening. But in Python, I have much less to go on when trying to track types, especially when user input is considered. So there's something to be said for forcing a type where you might be in doubt given lack of knowledge about the args. Given Python is not C or Java in design, especially with regard to types, it makes sense that it behave differently if it needs to (it should be true to itself, not to C or Java). In today's heterogenous programming environment, you have very different animals working together in hybrid situations. They shouldn't be forced to pay attention to how the others work, as long as they're consistent internally. Guido shouldn't have to turn to C or Java for guidance, and pro programmers should give up the idea that these two are to be regarded as hegemonic. Kirby From pdx4d@teleport.com Thu Jul 26 20:41:44 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Thu, 26 Jul 2001 12:41:44 -0700 Subject: [Edu-sig] PEP 238 - non-integer division In-Reply-To: <4.2.0.58.20010726121756.00bf8100@pop3.norton.antivirus> References: <3B6063B0.AA53BAFB@fa.disney.com> Message-ID: <4.2.0.58.20010726122839.00a9cdd0@pop3.norton.antivirus> At 12:24 PM 7/26/2001 -0700, Kirby Urner wrote: >>languages. This is especially troublesome since python is so often used >>in a hybrid C or Java environment. > >To argue the other side, C and Java both require you to >explicity declare the type of your variable, and the >rules of coercian tell you, in the code itself, when >a change is happening. But in Python, I have much less >to go on when trying to track types, especially when >user input is considered. So there's something to be >said for forcing a type where you might be in doubt >given lack of knowledge about the args. Last point, then I'll shut up re this thread: you might counter that by my argument a + b is as potentially ambiguous as a/b, as we don't necessarily know the types of a, b in either case, going in. That's true, but the core point to realize is that where ints and floats are concerned, a + b doesn't lose info (longs are another story). The problem with / is that it might lose info without telling us. b*(a/b) might not give us something close to a, whereas b+(a-b) always will return a (if a,b = int and/or floats). So the point is, when pushing ambiguous types through a potentially lossy operator, do we want to have an ambiguous or unambiguous result? The proposed design change opts for the latter. It's a reality check to make up for the weak typing of variables, the difficulty of tracking, lexically, the types of args involved. I think Arthur points too much emphasis on someone writing their own programs and following the unambiguous rules in the tutorial, vs. someone inheriting code written by others, and trying to puzzle out what's going on. The pro programmer (paid) is as likely to be in the latter situation as the former. It's the readability of code that we're after, long after the original coders are out of the picture, not just how easy it is to dash off something and have it do what you want (that's programming for self alone as reader, and is the hallmark of non-professional coding). Kirby From Arthur_Siegel@rsmi.com Thu Jul 26 22:23:38 2001 From: Arthur_Siegel@rsmi.com (Arthur_Siegel@rsmi.com) Date: Thu, 26 Jul 2001 16:23:38 -0500 Subject: [Edu-sig] re: More spillover re the division PEP Message-ID: <00886AB4.N22121@rsmi.com> Kirby writes - >I think Arthur points too much emphasis on someone >writing their own programs and following the unambiguous >rules in the tutorial, vs. someone inheriting code written >by others, and trying to puzzle out what's going on. If we are disagreeing, I'm not sure where. I thought we were coming to similar places - just from different angles. Kirby also writes - >In any case, these are all just hats. I'm a newbie >with respect to language A, casual user of B, non-user >of C, pro with D. Always a newbie, always a pro - >that's life in the big city. Here we are disagreeing. I liked where you started better - newbie in the sense of new to programming different from newbie in the sense of prior programming experience new to Python. Quite different. I attempt to add a third category. Scripter. You seem to disagree with my assertion that we need to be more explicit than "newbie" when discussing something like the divisor operator. Who stumbles, why, and what accommodation to their pre-existing expectations are possible or wise. I think it is impossible to speak productively of "newbies" as a group in having such a conversation - because all the conversation ends up being is about different peoples different definition of the word "newbie", caste as a discussion about something else. ART From kevino@tulane.edu Fri Jul 27 01:00:58 2001 From: kevino@tulane.edu (Kevin Ollivier) Date: Thu, 26 Jul 2001 20:00:58 -0400 Subject: [Edu-sig] re: More spillover re the division PEP References: <008843E4.N22121@rsmi.com> Message-ID: <015601c1162f$3753d740$6401a8c0@cox.rr.com> Hi Arthur, <> > Should the language be designed to prevent conceptual errors by folks > who haven't made it to Chapter 3 of its introductory tutorial. For > reasons that I can't even explain to myself, the argument that it should - > if and to the extent that argument has been advanced in these discussions > - makes me nuts. That's understandable - I've seen many people call themselves database designers simply because they can use Microsoft Access, although it is obvious from their work that they don't understand the conceptual issues involved. In fact, they break many of the essential rules the 'trained' DB designer is taught to uphold. To listen to someone advocate creating these kinds of workers would frustrate me as well. But in this case the errors do not occur because students do not understand the concept. They may understand the concept perfectly, but because they are so familiar with arithmetic and "calculator" division, and because they have been using these forms of division far longer and more often than integer division, they forget that Python does things differently and as a result create a "gotcha" in their code. They of course will remember this when an error occurs, but that could happen be in a production environment. > A more interesting argument is to what extent we should concern ourselves > about those with an interest in learning to program who who read Chapter 3 > carefully, and can't follow it - don't have the background to make any sense of > it. > > That's certainly worth talking about. But first we need to have some evidence > that such > a population exists, which we do not. Or that, if such a population does > exist, > programming language design is a reasonable arena in which to expect to be > able to offer them help[. I think we could safely say the current target audiences for Python should be old enough that they have a solid grounding in whatever pre-requisite knowledge they need to learn Python and programming in general. However, as you say it would be interesting to know what those pre-requisites are! After all, how long until 7-8 year olds start trying their hands at programming? (If they aren't already.) Kevin From pdx4d@teleport.com Fri Jul 27 02:03:57 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Thu, 26 Jul 2001 18:03:57 -0700 Subject: [Edu-sig] re: More spillover re the division PEP In-Reply-To: <00886AB4.N22121@rsmi.com> Message-ID: <4.2.0.58.20010726174535.00d0f980@pop3.norton.antivirus> > >If we are disagreeing, I'm not sure where. > >I thought we were coming to similar places - just from >different angles. I think I was responding to your sentiment that we don't want to pander to people who don't make it to chapter 3, i.e. if someone really learns the rules completely, then a/b, as currently defined, shouldn't be problematic. After all, it's all spelled out in black and white. You don't want Python to be dumbed down as it panders to some illusory "newbie" audience, a.k.a. people without the discipline to do enough learning. In the long run, it's better to have a steep on ramp than a dumbed down language. Whereas I agree with the sentiment, what I'm saying is that a/b is less problematic from a typical newbie standpoint of just trying to get something done in the language on one's own time. Typically, the posture of a newbie is: I want to program something that will do X, i.e. is one of writing from scratch. As such, the newbie is both the author and debugger of her own code, and therefore has deeper knowledge than lexemes like a/b taken in isolation. You can presume more insight and comprehension, because the reader is also the writer. Further along in a typical programming learning curve, you're not just writing your own stuff, but joining in teams, or inheriting code from others. You start eyeballing these vast programs, with thousands of lines of code, none of which you wrote. This is where you start to feel real gratitude for comments, clear documentation, cross-references. And this is where a/b starts to be problematic, because you don't know if it's losing information, returning 0 for 1/2 3/5 6/7 8/9... because you don't necessarily have all the clues you need to decide the types of a and b. Whereas if the proposed change is implemented, then I know for sure that a/b is a float-style division, and a//b isn't. It matters more with division, because a-b, a+b and a*b, if a,b are integers, usually don't give essentially different results than if a,b were floats. But with /, the current behavior is radically different either way. So it's not a matter of not understanding what / does for reason of not having read and/or understood the docs, it's a matter of knowing full well how / behaves, and finding this a stumbling block, especially because, unlike C or Java (especially Java), you don't have to declare the types of your arguments. In Java, you would go something like: int myfunc(int x, int y){ return x/y } Fine. myfunc expects two integers and returns an integer. No problem telling how / will behave. But in Python: def myfunc(x,y): return x/y How am I supposed to know that this does? It's not a matter of not having studied the docs, it's just that there's a lot more ambiguity built in to the language (by design). To compensate for that abiguity (an advantage, a selling point), we maybe need to be more explicity about what / is doing right where it's being used. This is what the PEP is aimed at fixing. Where I think we're agreeing is on the point that this has little to do with newbies vs. pros. However, I'm adding that I think the limitations of the current / are more likely to trip up a pro than a dedicated, serious- minded newbie, simply because pros are often immersed in the mundane drudgery of scanning large programs written by others, whereas the paradigm newbie is often more blissfully self-involved in pet projects, teaching herself the language, but not forced to rub her nose in a lot of code by others (except maybe the short examples offered in the tutorials and "How to" books). Kirby From ajs@ix.netcom.com Fri Jul 27 13:45:40 2001 From: ajs@ix.netcom.com (Arthur Siegel) Date: Fri, 27 Jul 2001 08:45:40 -0400 Subject: [Edu-sig] re: More spillover re the division PEP Message-ID: <000001c1169a$676c25c0$a9e1fea9@carol> Kevin writes: >They of course will remember this when an >error occurs, but that could happen be in a >production environment. Kirby writes: >However, I'm adding that I think the limitations >of the current / are more likely to trip up a pro >than a dedicated, serious-minded newbie And as boring as it might be, I essentially agree with the major points of both your posts. (Except that I am probably less sympathetic to the issues of someone who can't keep in mind that using a programming language is different than using a calculator) I recall for some reason in this context when I encountered a previously unreported JPython bug. It was a major victory for me to be able to eliminate all other possibilities and send up a bug report. The point of the story - if there is one - is that a few hours later someone (who had nothing to do with writing the original piece of code) comes back with the fix. Somewhere in the thousands of lines of Java code a ">" had to be a ">=". Issue gone. I looked at the offending code and the fix and didn't have a clue what was going on. But was awed that someone was able find it. And a little scared silly by a closer exposure to the rigor of the discipline. Though I hope this is not interpreted as lobbying for rigor for rigor's sake in a learning environment. I certainly understand that many of the more rigorous aspects of programming are hidden from me in Python's C code, and wouldn't have in at any way. But like all processes, there is a point of diminishing returns, and even a point perhaps where the process feeds back over itself. Whatever that might mean. ART PS - I thought I sent this note up last night. Don't see it posted. If duplicative, I apologize. From sorifu_info@ec-shock.com Fri Jul 27 18:11:05 2001 From: sorifu_info@ec-shock.com (=?ISO-2022-JP?B?GyRCJWEhPCVrJSIlcyUxITwlSDt2TDM2SRsoQg==?=) Date: Sat, 28 Jul 2001 02:11:05 +0900 Subject: [Edu-sig] =?ISO-2022-JP?B?GyRCPi5AdEZiM1UbKEIgGyRCO1k7fUlUO1k7fTZbNV4bKEI=?= =?ISO-2022-JP?B?GyRCJSIlcyUxITwlSBsoQg==?= Message-ID: <20010728.0211030549.babaq@sorifu_info-ec-shock.com> $B>.@tFb3U!!;Y;}!&IT;Y;}!!6[5^%"%s%1!<%H(B $B$*K;$7$$$H$3$m!"$4LBOG$r$*$+$1$7$^$9$,!"(B $B2<$N(BURL$B$r%/%j%C%/$7$F!"%"%s%1!<%H$K$46(NO$*4j$$$$$?$7$^$9!#(B http://211.9.37.210/koizumi/koizumi_an.asp?id=260083 From wilson@visi.com Sat Jul 28 01:21:27 2001 From: wilson@visi.com (Timothy Wilson) Date: Fri, 27 Jul 2001 19:21:27 -0500 (CDT) Subject: [Edu-sig] When to introduce OOP Message-ID: Hi everyone, I'm working on planning my Python course for this fall, and I'd like to get the group's advise on when I should introduce OOP. I work with Zope a lot and the OO paradigm is pretty deeply embedded there. I've really gotten to like it. (Not that I've mastered it. :-) Now I'm fully aware that Python is just as capable a procedural programming language as it is an OO one. I don't want to skip talking about that side of things, but OOP seems so prevalent in many areas that I'd like to get my students working with it as soon as possible. I'd appreciate any thoughts you might have on this topic. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.com W. St. Paul, MN | | http://slashdot.org wilson@visi.com | | http://linux.com From pdx4d@teleport.com Sat Jul 28 05:41:05 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Fri, 27 Jul 2001 21:41:05 -0700 Subject: [Edu-sig] When to introduce OOP In-Reply-To: Message-ID: <4.2.0.58.20010727213719.00d0a240@pop3.norton.antivirus> I agree: no need to delay OOP. Just as many urban areas are going directly to cell phone, because the land lines system is a mess (e.g. Budapest), so might newbies to programming start directly with OOP. No need for this "ontogeny recapitulates phylogeny" nonsense -- not really true in bio either, despite the hype. And it's not all that "either/or" either: procedural code is embedded inside of objects. Write a standard procedure and then swallow it, make it a part of some "thing" -- as easy to understand as digestion. The objects model is everywhere: any electronic gizo exports its API via its control panel. Interfaces to behind-the-scenes guts -- what could be more everyday? Kirby From cmeyers@guardnet.com Sat Jul 28 17:02:53 2001 From: cmeyers@guardnet.com (Chris Meyers) Date: Sat, 28 Jul 2001 08:02:53 -0800 Subject: [Edu-sig] When to introduce OOP Message-ID: Hi Tim, I just completed teaching a 15 hour little survey course on Python at the community college here in Eugene. It went pretty well, particuarly since it was the first time for me with this material. I tried to make the course sort of data-oriented. Concentrated on first simple data types, numbers and strings and then moved on to lists and dictionaries. Treated the rest of the language as just operators on the data, so introduced "for" along with lists, etc. We mostly played with small pieces of code, often at the interactive prompt. Near the end I introduced 2 larger programs. The first was strictly procedural, a tic-tac-toe that showed off functional decomposition pretty well. That was last week. In the last 3 hour class this week we first looked at object oriented stuff and then showed an OOP simulated card game. This game will be a chapter in the OBP book real soon now. People seemed to have no problem with OOP this early. Some of it might be that they were already used to composite data with lists and dictionaries. Including things like nested lists etc. So objects referencing other objects was ok. Tying methods to objects, no problem. Inheritance a little trickier but still ok. My impression is that the two programs were about the same in complexity and size. But my students had to struggle more with the procedural one. There were a lot more smiles this week than last. I think maybe it's all about being able to map the code to a model in your head. As Kirby said, you still got to use procedural code to stuff into the object methods. I vote for using OOP as early as you can and have them use it if they are writting programs. Set good habits early. Chris Meyers 07/27/2001 8:21:27 PM, Timothy Wilson wrote: >Hi everyone, > >I'm working on planning my Python course for this fall, and I'd like to get >the group's advise on when I should introduce OOP. I work with Zope a lot >and the OO paradigm is pretty deeply embedded there. I've really gotten to >like it. (Not that I've mastered it. :-) > >Now I'm fully aware that Python is just as capable a procedural programming >language as it is an OO one. I don't want to skip talking about that side of >things, but OOP seems so prevalent in many areas that I'd like to get my >students working with it as soon as possible. > >I'd appreciate any thoughts you might have on this topic. > >-Tim > >-- >Tim Wilson | Visit Sibley online: | Check out: >Henry Sibley HS | http://www.isd197.org | http://www.zope.com >W. St. Paul, MN | | http://slashdot.org >wilson@visi.com | | http://linux.com > > >_______________________________________________ >Edu-sig mailing list >Edu-sig@python.org >http://mail.python.org/mailman/listinfo/edu-sig > From ajs@ix.netcom.com Sat Jul 28 16:40:52 2001 From: ajs@ix.netcom.com (Arthur Siegel) Date: Sat, 28 Jul 2001 11:40:52 -0400 Subject: [Edu-sig] re: Changing the Division Operator -- PEP 238, rev 1.12 Message-ID: <000b01c1177b$c20f8da0$a9e1fea9@carol> from PEP 238, rev 1.12: >A unified numeric model removes most of >the user's need to be aware of different numerical types. >This is.good for beginners, but also takes away >concerns about different numeric behavior >for advanced programmers. FWIW, I think in here is a precise enough to be useful word for what I have always identified as the prime CP4E constituency - the "beginner". Someone at the early stages of a process. But within a process - formal or informal. Very different implications from the word "non-programmer" which, IMO, has very unfortunately been consistently used as a near synonym. I don't think that word has enough precision to be useful. And lack of language precision has been the real devil in all this, I happen to be quite convinced. With much less vehemence and confidence than I express the above opinion, I register my reservations about whether a unified numerical model is in the best interest of the beginner. Certainly I can see the "for" argument. Which is perhaps more consistent with a Programming for the Fun of It ideal, than is the source of my reservations. Reserve the right to mouth off only when a PEP addresses the needs of beginners as the *prime* motivation of a foundation level change. Trying to keep in mind that as Kirby says as to himself, I am not in the leadership - and it is the leadership with the track record, not me. ART From dustin@cs.uchicago.edu Sun Jul 29 17:12:28 2001 From: dustin@cs.uchicago.edu (Dustin Mitchell) Date: Sun, 29 Jul 2001 11:12:28 -0500 (CDT) Subject: [Edu-sig] re: More spillover re the division PEP In-Reply-To: <4.2.0.58.20010726174535.00d0f980@pop3.norton.antivirus> Message-ID: I hate to continue this thread, but I have a point I haven't seen yet: Ask a grade-school student who is at the point where she can divide integers, but hasn't learned about fractions or decimals, "What's 10 divided by 3?" She will answer, "3". Students initially learn division as a lossy operator, and only later (though not much later) learn that it can do more. Student's don't learn that this 'lossiness' is wrong -- they learn that it is one sense of division; one that is useful for long division and writing mixed fractions, for example. Similarly, those learning Python should learn the 'lossy' operator first, and should learn that the 'lossy' behavior is useful in many situations. They should learn about the 'lossless' form of division shortly thereafter, learn why they both exist, and learn that even 'lossless' division loses something on a computer. I agree that the current notation for 'lossless' division is clumsy and non-intuitive. I feel that changing the semantics of an existing operator will cause more compatibility problems[1] than adding a new operator with new semantics. So, if I were king of my own little universe, Python would get a new '//' operator which does 'lossless' division, and the '/' operator would retain its original semantics. 'course, I'm no king. :-) Dustin [1] Note there are two flavors of compatibility problems: old scripts on a new interpreter, and new scripts on an old interpreter. To maximize usability of the language, both combinations are important. )O( From dscherer@vysics.com Sun Jul 29 17:16:26 2001 From: dscherer@vysics.com (David Scherer) Date: Sun, 29 Jul 2001 12:16:26 -0400 Subject: [Edu-sig] re: More spillover re the division PEP In-Reply-To: Message-ID: <000301c11849$d315e030$8101a8c0@RABBIT> > Ask a grade-school student who is at the point where she can > divide integers, but hasn't learned about fractions or > decimals, "What's 10 divided by 3?" She will answer, "3". Grade school students learn long division, which is divmod() in Python - it returns a dividend and a remainder. So she will answer (3,1) ;) Dave From pdx4d@teleport.com Sun Jul 29 17:39:30 2001 From: pdx4d@teleport.com (Kirby Urner) Date: Sun, 29 Jul 2001 09:39:30 -0700 Subject: [Edu-sig] re: More spillover re the division PEP In-Reply-To: <000301c11849$d315e030$8101a8c0@RABBIT> References: Message-ID: <4.2.0.58.20010729093536.00a507a0@pop3.norton.antivirus> >vided by 3?" She will answer, "3". > >Grade school students learn long division, which is divmod() in Python - >it returns a dividend and a remainder. So she will answer (3,1) ;) > >Dave I agree. They say "3 remainder 1" -- gradeschoolers don't just toss the remainder. Although integer division is useful, it's more obscure than regular floating point. Even though converting / to floating, and using // for integer return is going to break more code, I think it's better in the long run, for all the new code as yet unwritten. There's some pain in changing such a basic, primitive feature in a language already in production. Going to case-insensitivity would have been an even bigger nightmare. I'm OK with Guido pushing ahead with the above, and am glad the CI issue is being dropped. Kirby