Mailman 3 October 2018 - 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

MineCraft with Python
by Jurgis Pralgauskis 04 Dec '22

04 Dec '22

Hi, intro: many kids like MineCraft :) probably you know/heared of MineCraft Pi https://www.raspberrypi.org/learning/getting-started-with-minecraft-pi/ But there seems to be Py for real MC http://coderdojotc.readthedocs.io/projects/python-minecraft/en/latest/ http://www.instructables.com/id/Python-coding-for-Minecraft/ PS.: a nice article (from js4MC world) https://github.com/walterhiggins/ScriptCraft/blob/master/docs/YoungPersonsG… -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

6 6

learning Unicode through Jupyter (with Python)
by kirby urner 29 Oct '18

29 Oct '18

Since full unicode is the current range of the default string type (str), I find my initial explorations of strings often swerve into chess pieces, playing cards, emoji. Speaking of playing cards: I'm surprised to discover an unfamiliar face card this late in life. Unicode has a "Knight" (letter C) in all four suits. I'm so used to Bicycle decks with suits of 13. I chop out all the Knights using slice notation in the Notebook linked below. The playing card motif is especially apropos around Python given the logo has that face card symmetry, if you know what I mean. I believe Luciano Ramahlo does playing cards quite a bit, along with little flag GIFs (served by nginx), which I think these days could be emoji. If not bothering with Unicode, then why not just: from random import shuffle suits = "Hearts Clubs Spades Diamonds".split() # chop me up royals = "Ace Jack Queen King".split() # could Ace be a she? Sure! normals = [str(i) for i in range(2, 11)] # starts at 1, stops at 10 deck = [ ] # I'm an empty list for s in suits: # outer loop for n in [royals[0]] + normals + royals[1:]: # Ace, normals, rest card = (n, s) # (suit, face value) deck.append(card) deck += ["Joker", "Joker"] # need these too! print("Fresh from box:\n", deck) shuffle(deck) print("Shuffled:\n", deck) But then we'd probably want instances of the Deck class no? Self shuffling. Besides, I think bothering with Unicode is worth the effort. Lets not lazily pretend we still live in the days of ASCII. Copying over from a publicly shared Jupyter listserv, one of mine from yesterday: === "Orthogonal" to the programming languages (yet pops up in most of them): Unicode. http://nbviewer.jupyter.org/github/4dsolutions/SAISOFT/blob/master/Unicode_… I'm finding Jupyter fun for exploring Unicode, in part because of HTML( ) enlargement possibility. I approach it through Python, but other kernels could do that too. I second Lee's enthusiasm for the Jake Vanderplas tutorials. He gave a great keynote at a Pycon I went to here in Portland. Kirby On Sun, Oct 28, 2018 at 8:19 PM Lee Smith <leesmith404(a)gmail.com> wrote: > > > On Wednesday, October 17, 2018 at 7:30:53 AM UTC-7, akash deep srivastava > wrote: >> >> hi i am akash i'am student of today i'am staring a jupyter . i dont know >> what is jupyter and what is the use so please help me and guide to jupyter . >> > > Jupyter is a Browser that easily allows programming experiments. First in > Python, now there are C++ kernels being adopted. You will find Juyper > very useful since on line a number of people are publishing free courses > written in a notebook. Consider https://github.com/jakevdp. One of > his 'Repitories' -- folders is a complete elementary course in Python. " > WhirlwindTourOfPython <https://github.com/jakevdp/WhirlwindTourOfPython>" > > > ===

1 0

"Data Science for Undergraduates: Opportunities and Options (2018)"
by Perry Grossman 12 Oct '18

12 Oct '18

FYI, National Academies of Sciences, Engineering, and Medicine; report that may be of interest to you. "Data Science for Undergraduates: Opportunities and Options (2018)" https://www.nap.edu/catalog/25104/data-science-for-undergraduates-opportuni… I just skimmed parts; looks interesting. But quite wordy and much higher level than the applied work I hope to get back to now, using Python. Perry

1 0

Jupyter Notebooks in the news again, thanks to Paul Romer Nobel Prize
by kirby urner 10 Oct '18

10 Oct '18

Some links: https://developers.slashdot.org/story/18/10/09/0042240/economics-nobel-laur… https://qz.com/1417145/economics-nobel-laureate-paul-romer-is-a-python-prog… Shades of Atlantic Monthly, April issue (mentioned in 2nd link): https://www.theatlantic.com/science/archive/2018/04/the-scientific-paper-is… Kirby

2 1

adventures in using Python as a calculator
by kirby urner 07 Oct '18

07 Oct '18

A stereotype some people have, of computers, is they're like giant calculators on steroids. Then they find as much "text processing" goes on as "number crunching" -- ala "regular expressions" -- and forget about the calculator model. Calculators don't do strings, let alone much in the way of data files. Of course that line got blurred in the golden age of programmable calculators (HP65 etc.). However, the Python docs start with Using Python as a Calculator in Guido's tutorial. Perhaps we could do more to fulfill the "on steroids" expectations (that the computer is a "beefed up" calculator device) by exploring our number types in more depth, and in particular by exploiting their superhuman abilities in the extended precision department. Yes, the int type is awesome, now that it integrates long int (for those new to Python, these used to be separate), but lets not forget Decimal and also... gmpy, or actually gmpy2. I've probably lost even some seasoned Python teachers in jumping to that relatively obscure third party tool, providing extended precision numeracy beyond what Decimal (in Standard Library) will do. gmpy has a long history, predating Python. I'm not the expert in the room. In particular, it does trig. Our Python User Group used to get one of the package maintainers from nearby Mentor Graphics (Wilsonville). He was adding complex numbers to the gmpy mix, and was in touch with Alex Martelli. I enjoyed our little chats. Without having all the higher level math it might take to actually prove some identity, and while starting to learn of those identities nonetheless, extended precision would seem especially relevant. "Seriously, I can generate Pi with that summation series?" Lets check. Just writing the program is a great workout. Some subscribers may recall a contest here on edu-sig, for Pi Day (3/14), to generate same to a 1001 places, given one of Ramanujan's convergence expressions for the algorithm. https://github.com/4dsolutions/Python5/blob/master/Pi%20Day%20Fun.ipynb http://mathforum.org/kb/thread.jspa?threadID=2246748 I had an adventure in gmpy2 just recently when my friend David Koski shared the following: from math import atan as arctan Ø = (1 + rt2(5))/2 arctan( Ø ** 1) - arctan( Ø ** -1) == arctan(1/2) arctan( Ø **-1) - arctan( Ø ** -3) == arctan(1/3) arctan( Ø **-3) - arctan( Ø ** -5) == arctan(1/7) arctan( Ø **-5) - arctan( Ø ** -7) == arctan(1/18) arctan( Ø **-7) - arctan( Ø ** -9) == arctan(1/47) arctan( Ø **-9) - arctan( Ø **-11) == arctan(1/123) ... Without offering any kind of algebraic proof, I just wanted to see if the arithmetic panned out. These denominators on the right turned out to be a "bisection of the Lucas numbers" (like Fibonaccis with a different seed). That's a great job for a Python generator, and only integers are involved. But am I really confined to verification (not proof) using floating points? Not at all. At first it seemed that way thought, because whereas Decimal supports powering and roots, it's not equipped with atan. Then I remembered gmpy2 and could all of a sudden push the number of verifying decimals out past 92. Definitely a calculator couldn't do this. https://github.com/4dsolutions/Python5/blob/master/VerifyArctan.ipynb Math students the world over, if free of the tyranny of calculators -- or at least allowed to aid and abet (supplement) with Raspberry Pi etc. -- get to dabble in these industrial strength algorithms, a part of their inheritance. Indeed lets use Python as a calculator sometimes, in accordance with said Python.org tutorial. A much stronger calculator, with a bigger screen, more keys, and a lot more horsepower. Kirby PS: I ran into this problem with gmpy2.atan: the above convergence wasn't verifying beyond like 19 digits. When I switched to gmpy2.atan2 istead, everything started to work out. The question being, why should atan(x) vs atan2(y,x) differ except in terms of API? gmpy2.atan2(y,x) computes the arctan of y/x but in some other way apparently. Food for thought. I did do some digging in the docs.

2 1