Mailman 3 May 2015 - Edu-sig

a short essay about programming
by kirby urner 08 Dec '22

08 Dec '22

A common "error" (not too serious) that I see in beginning Python (and no doubt other languages, but Python is the one I'm teaching), is having a while condition that appears to put a lid on things, but then the flow all leaks away through break statements, such that the "front door" condition is never revisited. while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") break else: print("Nope, try again...") What's messed up about the above code is you never really go back to the top in the case where you'd get to leave. Rather, you exit by the back door, through break. So in that case, wouldn't have been simpler and more elegant, even more "correct" (dare I say it) to have gone: while True: # no ifs ands or buts guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") break else: print("Nope, try again...") I see lots of heads nodding, and that could be the end of the matter, but then a next question arises: wouldn't this also be a more correct solution?: while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") continue # instead of break else: print("Nope, try again...") We're back to having a variable while condition, not a boolean constant, but this time we actually exit by means of it, thanks to continue or... while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") else: print("Nope, try again...") ... thanks to no continue. This last one is getting a thumbs up, but then I'd pause here and say "continue" can be easier on the eyes. It's unambiguous where it takes you, in contrast to having to scan on down the gauntlet, looking for possibly other open doors. "What happens next" should not require scanning ahead too far. Help us not to get lost. Be a civic-minded coder. I'm thinking of a programming style that advises two things: (a) if you use a while condition that's variable, that's expected to change, then your goal should be to always exit because of that, i.e. that should be your only exit point. Even if some other criterion suggests exiting, you have the option to flip that "lid" at the top, to crack that front door, and bounce the ball out. (b) which is why 'continue' is your friend. You are showing the user where your 'break' statements are, except you don't use "break" statements, as you've given a non-constant condition, and your aim is to make that your ONLY exit point. In short: never use break to exit a while loop unless your condition is while True. Instead, always flip the condition and exit through the font door. However, as soon as I make that rule I can think of good reasons to break it. The other programmers in the room are shaking their heads. Won't we lose information, needed elsewhere in the program, if we "artificially" force a True condition to False. Aren't we, in effect, lying? That concern could be addressed. Keep all the info true, just treat the "lid condition" (it "keeps a lid on it") as a flag. Go ahead and remember the user's guess. allowed = 5 tries = 1 exit = False while not exit: # no other way out guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") exit = True # instead of break continue print("Nope, try again...") tries += 1 if tries == allowed: print("You've maxed out") exit = True continue I think we all understand the main issue: writing reader-friendly code, and rules for doing so. There's something comforting about approaching a while loop and knowing its not a leaky sieve, riddled with back doors, maybe even an exit( ) time bomb. But in the recursion world we want a minimum of two exits usually: when another round is called for versus when we've "hit bottom". Can we have it both ways? Conclusions: Lets not be too hasty with rules of thumb and: Lets keep the reader in mind when writing code. Just because the interpreter knows to compute the flow unambiguously, doesn't mean all ways of writing it are equally reader-friendly. What may seem a gratuitous gesture, an unnecessary flourish, may actually promote reader comprehension of your code, and that should be a goal as much as satisfying the interpreter. Kirby

8 17

turtle coordinates: Y increase downards - as in most graphics API?
by Jurgis Pralgauskis 02 Jul '18

02 Jul '18

Hi, usually in computer graphics Y is counted to increase downwards. I casn do it with: setworldcoordinates(0, 400, 600, 0) but then, "right(..)" turns to the left :/ I could swap: right, left = left, right but on errror I get a bit misleading message >>> right() Traceback (most recent call last): File "<pyshell#10>", line 1, in <module> right() TypeError: left() takes exactly 1 argument (0 given) I thought to make this hack for kids, so better clearer error msgs... Any Ideas? Thanks :) -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

6 20

Distance Learning: where and how
by kirby urner 06 Jun '15

06 Jun '15

I take a debate-encouraging position against the standard cohort-based, curve- and letter-graded style of teaching in this blog post from when I was the USDLA (distance learning) conference: http://worldgame.blogspot.com/2015/04/against-grain.html But we have more in common than what divides us, as distance learning schools, I'm thinking. Especially those of us coming in from outside, experimental and unaccredited (but what's to stop Michigan from offering math credit to a high schooler taking our Python sequence? -- nothing but red tape?). This article is making the rounds a work today: http://www.bloomberg.com/news/articles/2015-05-07/coding-classes-attract-co… More discussion on python-cuba: https://mail.python.org/pipermail/python-cuba/2015-May/000037.html Kirby

1 1

talking about "operators" in Python namespace
by kirby urner 23 May '15

23 May '15

http://mathforum.org/kb/message.jspa?messageID=9780027 >From math-teach

1 0

"little lambda" again
by kirby urner 23 May '15

23 May '15

We know the Great Lambda languages like LISP and Scheme have lambdas that might go on for pages, whereas Python has a "little lambda": one expression only. That expression may be another lambda however, and perhaps worth doing, to get the concept of composing functions across, we might in math class go: compose = lambda f, g: lambda x: f(g(x)) # Example functions def addA(s): return s + "A" def addB(s): return s + "B" # Composing them addAB = compose(addB, addA) # Test print(addAB("L")) Getting LAB for output i.e addB(addA("L")) Over on math-teach I've been branding our traditional differential / integral calculus the "Delta Calc" track to pave the way for an additional "Lambda Calc" track through much of the same territory. Lambda Calc is our door into Gnu Math more generally, a complementary CS-friendly approach to many of the same high school math concepts. but also new ones not hitherto so commonly seen. We'll do more with RSA and Fractals than in the previously status quo standards, and with spatial / spherical geometry per Popko. [1] Lets get those Tractors on the ball (Spaceship Earth). The "everything is an object" heuristic in Python makes it natural to think of functions as arguments as well as results of other functions. Kirby [1] http://www.dividedspheres.com/

1 0

student privacy and Gnu Math
by kirby urner 19 May '15

19 May '15

Discussion of student privacy, especially cyber-privacy on math-teach, including my reply re the efficacy / relevance of "Gnu Math": http://mathforum.org/kb/thread.jspa?threadID=2706045 Kirby

1 0

confirming dict def behavior with gender diversity dict
by kirby urner 18 May '15

18 May '15

I was playing with this somewhat dated and not fully accepted key or legend the gender diversity people sometimes use: . diversity_acronyms = {'G':'Gay', 'L':'Lesbian', 'T':'Trans', 'B':'Bi', 'Q':'Queer', 'Q':'Questioning', 'H':'Hetero', 'I':'Intersex', 'P':'Pan' } . diversity_acronyms.keys() dict_keys(['Q', 'P', 'B', 'T', 'G', 'I', 'H', 'L']) . diversity_acronyms['Q'] 'Questioning' Yes, given it's a mapping we all know that there's no special ordering of the keys or the items in general i.e. QPBTGIHL is but one permutation. But my question is regarding key unique-ness: (we lost a Q) and the rules of precedence at define time. Do we always lose the *same* Q? i.e. in defining the dict top to bottom (above and again below), I mention a 2nd 'Q' after a first, so I'm confirming it would always be the last of any given key that survives to be in the dict final dict. Testing: . diversity_acronyms = {'G':'Gay', 'L':'Lesbian', 'T':'Trans', 'B':'Bi', 'Q':'Questioning', 'Q':'Queer', 'H':'Hetero', 'I':'Intersex', 'P':'Pan' } . diversity_acronyms['Q'] 'Queer' Right, I'm guessing this is in the docs somewhere. I think I've answered my own question. My question for diversity-sig would be: do folks here think there'd be strong objections to replacing 'Q' for 'Queer' with 'P' for 'Pan' which is a relatively new one, meant more as a rounding-out catch-all I think? But that's what 'Queer' used to mean originally: "anything broader minded than boring straight" (rough translation). Queer was the parent class with any narrowing to G, L, H, B considered subclasses of a more generic API. Given a dict needs a unique key per value, the goal in replacing 'Queer' with 'Pan' as the base class (and dict key) in some implementations, is to more conform to Pythonic semantics (unique key requirements) while preserving the gender diversity spectrum already in the cards (this acronym is not my invention, is well-known in GLTBQ literature). But this is edu-sig not diversity-sig and I'm mainly just confirming that the order in which keys in a dict are defined determines, in a deterministic / predictable manner, which value survives. Kirby

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 142, Issue 9
by Marianne McKenna 18 May '15

18 May '15

I am away from the office - returning on Monday- May 18th. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 142, Issue 8
by Marianne McKenna 17 May '15

17 May '15

I am away from the office - returning on Monday- May 18th. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 142, Issue 7
by Marianne McKenna 16 May '15

16 May '15

I am away from the office - returning on Monday- May 18th. I will try to respond by email. If you need immediate help, please contact tech support. Thanks!

1 0