[Edu-sig] Re: Edu-sig digest, Vol 1 #15 - 4 msgs
sam schulenburg
samschul@pacbell.net
Wed, 09 Feb 2000 20:15:31 -0800
----- Original Message -----
From: <edu-sig-request@python.org>
To: <edu-sig@python.org>
Sent: Wednesday, February 09, 2000 9:00 AM
Subject: Edu-sig digest, Vol 1 #15 - 4 msgs
> Send Edu-sig mailing list submissions to
> edu-sig@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.python.org/mailman/listinfo/edu-sig
> or, via email, send a message with subject or body 'help' to
> edu-sig-request@python.org
>
> You can reach the person managing the list at
> edu-sig-admin@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Edu-sig digest..."
>
>
> Today's Topics:
>
> 1. More re "Python Notation" (Kirby Urner)
> 2. RE: Rational Division (Jeffrey Kunce)
> 3. Re: Rational Division (Frank Stajano)
> 4. Re: Rational Division (Gerrit Holl)
>
> --__--__--
>
> Message: 1
> Date: Tue, 08 Feb 2000 09:15:41 -0800
> To: edu-sig@python.org
> From: Kirby Urner <pdx4d@teleport.com>
> <s89ef61d.093@mail.conservation.state.mo.us>
> <000201bf71ff$ad48ece0$d92d153f@tim>
> Subject: [Edu-sig] More re "Python Notation"
>
>
> I meant to shut up for a week and concentrate exlusively
> on writing Xbase for money, but this edu-sig is just too=20
> interesting -- can't resist...
>
> Math notations assume human "parcers" -- increasingly=20
> numerate readers as the training progresses. A lot of=20
> work goes into getting those humans "programmed" to read=20
> without stumbling.
>
> Software engineers typically have two "clients" for their=20
> output, a stupid but extremely fast and efficient machine
> on the one hand, and the "naive user" on the other. =20
>
> The progammer is the mediator, writing all sorts of error=20
> checking into the code, trying to anticipate what that
> "naive user" might do (or a malicious hacker) and trying=20
> to protect the integrity of the application (keep it from=20
> crashing and/or becoming hopelessly confused).
>
> Some of what I'm doing with Python flies in the face of=20
> all this "reflex conditioning" on the part of programmers.
> I'm not trying to make robust code that runs on expensive=20
> computers, where crashes mean big bucks, angry clients,=20
> loss of jobs.
>
> Rather, I'm going back to the "trained human readers" paradigm=20
> (not naive). They're reading Python as an alternative way=20
> to express some ideas, such as:=20
>
> * how to generate Pascal's Triangle using expressions=20
> with factorial in them=20
> * how to spit out the number of spheres in a triangular,=20
> square, cubic, half-octahedral or cuboctahedral packing =20
>
> I've posted some code for all of the above in earlier posts,=20
> except for this last, which I'll give here:
>
> def cubocta(L):
> # L is number of layers in a cuboctahedral packing
> # Returns cumulative number of spheres
> return (10.0/3.0)*L**3 + 5*L**2 + (11.0/3.0)*F + 1
>
> In action:
>
> >>> cubocta(1)
> 13.0
> >>> cubocta(0)
> 1.0
> >>> cubocta(2)
> 55.0
> >>> cubocta(100)
> 3383701.0
>
> Notice: I don't check for negative numbers (which in this
> case would actually work -- but have no geometric interpretation=20
> in this context -- i.e. are "meaningless"). L is supposed to=20
> be "the number of layers around a nuclear sphere" and is a whole=20
> number. In my classroom context, it may be assumed that students=20
> simply know this. We aren't going to clutter the function with=20
> a lot of error trapping.
>
> Here's a web page with an animated GIF showing a growing=20
> cuboctahedron, plus other animations showing how this relates
> to crystallography. I did these GIFs using Java + Povray,=20
> but could have done them using Python + Povray (I just=20
> hadn't written oop7.html yet):
>
> http://www.inetarena.com/~pdx4d/ocn/xtals101.html
>
> Although math books include the concept of "domain of a function"=20
> (as one subscriber pointed out by private email), the economy=20
> of expressions like n!/k!(n-k)! depend on our _not_ cluttering=20
> the notation with a lot of redundant "error checking" to make=20
> sure the archetypal "naive reader" doesn't substitute -10,=20
> Root(2), or a character string for n or k. =20
>
> In a "for humans only" text, you've codified the "domain" of=20
> factorial elsewhere, probably in a different book, at a different=20
> grade level. Now you just assume all this "context sensitivity"=20
> on the part of your readers -- something software engineers=20
> have rarely felt their workaday world allowed them to assume=20
> (machines don't do context, and the naive users need to have=20
> their errors trapped).
>
> So, as a classroom-focused math teacher, my bias is different=20
> from the software engineer's. The Python I write is for human=20
> readers to scan and comprehend, much as they learn to scan=20
> and comprehend those "crypto-compressed" math notations we=20
> already expect them to learn (a lot of geeky greek letters,=20
> like SIGMA, PHI, PI, THETA). =20
>
> Plus Python has the added benefit of being machine-interpreted=20
> out the back -- so you can set up these interactive situations=20
> with a computer that offer immediate feedback and reinforcement. =20
> Every time you test an expression or short function definition,=20
> you get rewarded with a response (kind of like having a text=20
> book with "answers in the back" -- you can immediately confirm=20
> your understanding, or lack thereof).
>
> So, now that I've set up all this context, I will conclude by=20
> appending a real life post to the Association of Mathematics=20
> Teacher Educators (AMTE) listserv. I don't mention Python by=20
> name, but you'll see how I'm practicing this very philosophy=20
> in that context:
>
> ------------------------------------------------
> Archived at the Math Forum=20
> thread =3D http://forum.swarthmore.edu/epigone/amte/belgandjy
> ------------------------------------------------
>
> Subject: Re: substitution
> Author: Kirby Urner <pdx4d@teleport.com>
> Date: Sun, 30 Jan 2000 16:36:19 -0800
>
> > =3D Sally
> =3D Kirby
>
> > For another example with perhaps makes is clearer,=20
> > f(x)=3Dx^2, g(x)=3Dx+1, find f=B0g(x) and g=B0f(x). (The symbol =B0
is=20
> > a degree sign on my keyboard, the closest I can come to the=20
> > composition symbol, but it might not be that on others'
> > screens.) When this is first introduced at least half of=20
> > the students will give me f=B0g(x)=3Dx^2+1 AND g=B0f(x)=3D(x+1)^2.
>
> When doing composition of functions, I might have a student
> perform the role of x + 1. "Whenever someone gives you a number,
> your job is to simply add 1 to it and hand it back." =20
>
> Sally takes that job. We test it out a few times. Looks like=20
> she's got the hang of it. Sally(x) =3D x + 1
>
> Frank's job is to multiply a number by itself and return the=20
> result. We do a little job training to make sure he's got it=20
> down. Fred(x) =3D x * x
>
> So let's say I start with 3 and hand it to Sally. I get back 4.
> Now I take my 4 and hand it to Frank. I get back 16. Suppose
> I go in the reverse order. I start with 3 again, get back 9=20
> from Frank and then 10 from Sally. Different answer. Order
> matters.
>
> Or we could talk about other operations, besides those dealing
> with numbers. =20
>
> Sally paints anything she's given the color red.
>
> Frank paints green polka dots on whatever he's given. =20
>
> So if I give this toy horse to Sally first, then Frank, I get=20
> back a red horse with green polka dots. But what happens if=20
> I give it to Frank first and then Sally? Again, order matters.
>
> Frank(Sally(horse)) --> red horse w/ green dots
> Sally(Frank(horse)) --> horse is completely red (dots=20
> painted over)
>
> If my class has access to an interactive command line (as per=20
> earlier posts re my favored model of a math class), they could=20
> explore composition of functions by writing two definitions=20
> and taking g(f(x)) vs f(g(x)) -- no need for the little circle=20
> symbol I don't think, or we can show them that later (it's=20
> somewhat redundant). I'd expect students to make up their=20
> own functions and test the outcomes of composition.
>
> And again (as per my last post), I'd like to *move away*=20
> from:=20
>
> (a) the idea that operations are always about numbers (real=20
> or otherwise) and=20
> (b) the convention of using single letters for method and
> variable names
>
> On the contrary, I want my students to:
>
> (a) see "operations" as more generic than "number functions"
> (b) get in the habit of using longer strings to name their
> variables and operations
>
> In the example below, I follow my own advice:
>
> >>> 'A'*3 =20
> 'AAA'
>
> [Note: when used with a characters, the operators * and +=20
> mean 'repeat' and 'concatenate' respectively. This exercise
> presumes students are already quite familiar with this=20
> behavior.]
>
> >>> def Sally(input):
> return input * 3
> =09
> >>> def Frank(input):
> return "CA"+input
> =09
> =09
> >>> Frank("T")
> 'CAT'
> >>> Sally("T")
> 'TTT'
> >>> Frank(Sally("T"))
> 'CATTT'
> >>> Sally(Frank("T"))
> 'CATCATCAT'
>
> In the exercise given:
>
> f(x)=3Dx^2, g(x)=3Dx+1
>
> f=B0g(x)=3D ?
>
> I might write an alternative next to it, such as:
>
> temp =3D g(x)
> answer =3D f(temp)
>
> This makes it clearer that the output of the innermost
> function is the input of the enclosing function. Or I might=20
> use concentric circles, with g inside of f (I've seen text=20
> books that do this).
>
> I'm sure other list members have tried many of these ideas
> (plus many more), with varying degrees of success.
>
> Sometimes it's just the notation that's confusing, and switching=20
> to some other notation, while keeping all the ideas intact, clears=20
> up some conceptual confusions. Then you can go back to the original=20
> notation, with more confidance that the concepts are well-anchored.
>
> Kirby
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> None of this means that I'm "against" using Python in other
> ways (e.g. to teach computer programming). It's a great
> segue into all kinds of other patterns of usage. But I=20
> just wanted to be clearer about my model, which owes a lot
> to Iverson's APL. APL is the first programming language=20
> I ever learned, and it was love at first sight. And APL,
> as some of you know, was originally a chalk board notation. =20
> It was designed for sophisticated human readers, _plus_ it=20
> had the advantage of being executable in silicon circuits.
> Just amazing.
>
> Kirby
>
>
>
>
> --__--__--
>
> Message: 2
> Date: Tue, 08 Feb 2000 11:52:46 -0600
> From: "Jeffrey Kunce" <kuncej@mail.conservation.state.mo.us>
> To: <edu-sig@python.org>
> Subject: RE: [Edu-sig] Rational Division
>
> [Tim Peters]
>
> > I don't buy into this. Python's closest predecessor (ABC) *was* =
> designed to
> > be maximally unsurprising (via iterative user testing and redesign), and
> > ended up a self-contained universe, thoroughly isolating its users even
=
> from
> > their native filesystem ("too quirky"). Python tries to regularize the
=
> mess
> > that is the "real computing world", but doesn't try to deny or hide its
> > existence. CP4E's goals seem much more in tune with that latter.
>
> I'm not sure that CP4E's goals are that well defined. There were a lot
> of proponents for "Everyone" being virtually everyone. The Alice people
> are proceeding on that premise, and they are the ones who brought up
> the case and division issues.
>
> My opinion is that CP4E should concentrate, initially, on serving those=20
> who already *want* to learn or teach programming, but who are frustrated
> because of lack of resources and because of the mess you refer to.
> From this POV, I think python is pretty darn good just as it is
>
> --Jeff
>
>
>
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 08 Feb 2000 22:45:27 +0000
> To: gerrit@nl.linux.org, Tim Peters <tim_one@email.msn.com>
> From: Frank Stajano <fstajano@uk.research.att.com>
> Subject: Re: [Edu-sig] Rational Division
> Cc: edu-sig@python.org
> <s89ef61d.093@mail.conservation.state.mo.us>
> <000201bf71ff$ad48ece0$d92d153f@tim>
>
> At 2000-02-08 15:21 +0100, Gerrit Holl wrote:
> >2/3 is 0 rest 1. That's what I learned when I was 7, 8 years old.
>
> I won't question what you learnt when you were little, and indeed
different
> primary schools in different parts of the world may follow very different
> systems; but at mine they would have failed me in arithmetic unless I
> upgraded that answer to 0 rest 2 ;-)
>
> Frank (http://i.am/filologo.disneyano/)
http://www.uk.research.att.com/~fms/
>
>
>
> --__--__--
>
> Message: 4
> Date: Wed, 9 Feb 2000 08:14:09 +0100
> From: Gerrit Holl <gerrit.holl@pobox.com>
> To: Frank Stajano <fstajano@uk.research.att.com>
> Cc: Tim Peters <tim_one@email.msn.com>, edu-sig@python.org
> Subject: Re: [Edu-sig] Rational Division
> Reply-To: Gerrit <gerrit@nl.linux.org>
> Tim Peters <tim_one@email.msn.com>, edu-sig@python.org
>
> Frank Stajano wrote on 950046327:
> > At 2000-02-08 15:21 +0100, Gerrit Holl wrote:
> > >2/3 is 0 rest 1. That's what I learned when I was 7, 8 years old.
> >
> > I won't question what you learnt when you were little, and indeed
different
> > primary schools in different parts of the world may follow very
different
> > systems; but at mine they would have failed me in arithmetic unless I
> > upgraded that answer to 0 rest 2 ;-)
>
> Oops!
> 0 rest 2, of course.
>
> regards,
> Gerrit.
>
> --
> Homepage: http://www.nl.linux.org/~gerrit
> -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
> Version: 3.12
> GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O
> !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
> -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth
>
>
>
> --__--__--
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://www.python.org/mailman/listinfo/edu-sig
>
>
> End of Edu-sig Digest_______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://www.python.org/mailman/listinfo/edu-sig