Building a ship in a bottle

Lately I’ve been having a lot of discussions with people about Computer Science education. Everyone I’ve spoken with is passionate and excited about broadening the reach of CS education, which is really exciting to me: it’s exactly what I want to help with. One thing I’ve been frustrated by, from time to time, is not having a common understanding of what Computer Science education is. I’m not going to say I have the one true definition, but I thought I’d document my thoughts on it so that folks know what my perspective is.

One boon for marketing CS education is that everyone has an amazing supercomputer in their pocket, which can (and often does) run amazing programs; immersive games, augmented reality planetariums, music instruments, social media, and on and on. Being able to say to someone “I can teach you how to make these things and more – only limited by your imagination” is a great lure. It’s also misleading, and here’s where my analogy comes in. I think a smartphone and all of its apps are a lot like a phenomenal Ship in a Bottle. Offering to teach someone how to make an App is a lot like teaching someone how to make a ship in a bottle, without teaching them how to make a ship outside of a bottle first. Sure it’s possible, but it’s missing out on a number of opportunities:

First, you’ll never be able to make better looking ships in a bottle than you can outside of a bottle. If you want to innovate – make new, cool things that have never been seen before – you should experiment making those things outside of a bottle first, then once you’re happy with them, figure out how to get them assembled inside of a bottle.

Second, to have any chance of getting a novice shipbuilder to make anything they’ll consider acceptable inside of a bottle, you’ll have to give them a lot of parts pre-made, already in a form that can be put in a bottle. After your lesson, if they want to reproduce the experience at home, they’ll have to start with the same parts, which are essentially ship in a bottle kits. If those kits aren’t available, they’ll have to figure out how to back-fill the knowledge to construct them.

Third, and this is where the analogy stretches its limits, if bottle technology changes, the kits immediately become obsolete, and only folks who know how to build these things from scratch will have any chance of keeping up with technology.

For me, the notion of building a ship in a bottle is very much like getting a program to run on any computer, not just a smart phone. Taking a high-level idea of a game, an application, a musical instrument, and turning it into the 1’s and 0’s of the machine code for a specific computer, is a lot like building a ship in a bottle. Computers are crazy time-and-space dilating machines that require processes be expressed in very specific ways (the machine code), and when they are, those processes run at almost-unimaginable speed.

Teaching someone “game coding” using a high-level framework is akin to giving them a Ship in a Bottle Kit, and maybe even a bottle with a hinged bottom. After the class, if you give them a real bottle and raw materials, (no framework), they won’t be able to reproduce that experience.

I’m not saying these experiences are bad at all. In fact, I think they’re great for giving students a sense of “here’s where we’re headed,” and “cool stuff is possible.” But if the only focus is on using kits, students will be fundamentally unprepared for the world where computers, operating systems and languages change with a 3-5 year cycle.

So, what am I advocating?

Teaching someone how to build a ship outside of a bottle includes:

• Teaching them about how all computers work, all the way from gates, through logic and memory, up to machine code,
• teaching them about decomposing big problems into smaller steps, and assembling those steps into solutions, and doing so in the context of actually solving problems,
• teaching them about algorithms: use, implementation, analysis (Big Oh)
• teaching them about abstraction: using and creating your own,
• … and more. I think this is very much aligned with the current notions of computational thinking, and the recent AP CS principles curriculum.

An example I particularly like is Google’s CS Unplugged, which is an extreme example of learning about computer science concepts outside of the bottle of computers. Their activity with a Binary Sorting Network can be done on a playground with chalk, and blows kids’ minds when they come out sorted, regardless of what order they start with.

Systems like MIT’s Scratch might seem too much like a ship in a bottle kit in my analogy, but in my (admittedly limited) experience, once a student gets Scratch, they understand programming in a fundamental way. Scratch turns syntax – the icky, in-the-way stuff about programming – into a puzzle-assembly problem, so the students can focus on what they want to express. Later, when they are ready for textual-based programming, the syntax of those languages, when laid out with discipline, actually looks a lot like the similar Scratch program. Brilliant design on their part. The key to making this work is to keep the students exploring, make sure they keep learning from cool projects they like on the website, until they can pretty much create anything they want.

When teaching programming, I wholeheartedly recommend (when possible) teaching more than one language in a short duration. When I took Intro to CS at UC Berkeley (in 1984!), they taught us Scheme and C in the same year. Looking back on the experience, I think it was really clever: I learned the things that are fundamentally the same between the two, and also the things that are way better in one than the other. Choice of language is a choice of tool, and Mr. Natural’s “get the right tool for the job” was drilled in to me by my hippie dad from an early age.

While it’s totally okay to teach “writing Apps”, or “coding webpages”, it’s important to realize and advertise the limitations (and strengths) of these approaches. Knowing how to “code a webpage” was a lucrative skill in 1999, but quickly became irrelevant as Web technologies advanced. Similarly, we’re way past the time when simply writing an App and uploading it to Apple or Google is the road to a career. The role of teaching these things is to give an early glimpse at what’s at the end of the journey of a CS education. The peril of only using those approaches is that you’re on a never-ending treadmill of needing to take the next class when a new framework or web technology takes over, making your previous skills irrelevant. To stand the test of time, classes like this should include  fundamentals of usability and visual design, not just HTML, CSS and Javascript. On the games side, spend some time investigating what makes an activity fun, not just how to animate sprites using frameworks. Bonus points, on the games side, would be to include learning principles of physics, using a physics simulation framework.

One quote that resonates with me, often misattributed to Edsger Dijkstra, is “computer science is no more about computers than astronomy is about telescopes.” I think this quote may have been mis-used to try to push CS into Math departments, and is at odds with the accurate observation that the pre-eminent professional society dedicated to CS is named The Association for Computing Machinery. I think it’s safe to say that CS is something new: we spend too much time arguing about whether it’s a science, a branch of mathematics, an engineering discipline, or a vocational discipline – it’s all of those things. If you leave any aspect out, you’re missing out on something. Combining them isn’t easy, but if we manage to do it, we’ll be totally surprised at the kinds of things future generations will be building in these amazing bottles.

I’ve got a lot more to say on the subject of CS education, and even about the analogy (compilers are like CNC machines-in-a-bottle), but I’ll stop here for now.

Addenda: less than a week after writing this, I received the latest issue of CACM, and in it was a nice piece titled “Misconceptions About Computer Science.” I think there’s a lot of overlap in philosophy, and I’ve also got some stuff to learn from the authors who have been thinking about these issues for longer than I have, but I was encouraged.

Building and using a Paper Enigma

As part of the book about cryptography, math and programming I’m writing, I’m encouraging readers to assemble their own paper Enigma machine. Since it’s pretty involved, I thought I’d write an illustrated blog post about doing it. I’m going to start with a summary of the context of the Enigma – and as a summary, I’ll gloss over some likely-important stuff, and also probably get some things a bit wrong. Corrections are welcome, of course. So, here we go!

First, the whole idea of making a paper replica of the Enigma came from the amazing Alan Turing, the British mathematician who is the topic of a decent movie, a great book, and is generally credited as being a pioneer of computers, artificial intelligence, and for shortening World War II by two years (and dare I say, perhaps keeping the Nazi’s from winning?) The story isn’t all rosy: he was also gay at a time in the U.K. when that was a punishable crime, and he eventually killed himself due to his treatment by the government. It wasn’t until 2013 that the Queen pardoned and thanked him for his service. As Martin Luther King Jr. said, “The arc of the moral universe is long, but it bends towards justice.” That’s certainly true in this case.

Thinking back to World War II, the German military was kicking butt all over Europe, and their submarines were causing  all sorts of mayhem in the Atlantic. They were able to securely communicate across vast distances by sending radio messages that were encrypted with an Enigma machine. This meant that the Allies could hear their messages, but couldn’t understand them, because they didn’t have the key used to decode them. Polish mathematicians cracked the Enigma code in 1932, taking advantage of a subtle misconfiguration of how the Germans used the machines. By 1938, Germany fixed this flaw, and was able to send secure communications again.

One of the first things Turing did at Bletchley Park was to create a model of the Enigma machine using comic strips. Our paper Enigma, from Franklin Heath (a security firm in the UK), was inspired by his work. The first thing you’ll need is the PDF of the paper Enigma. Since paper in the US isn’t the same shape as in the UK (A4), I had good luck printing it on legal sized paper (11×14 inches). The kit is designed to be wrapped around a cardboard tube that is 75mm in diameter. It turns out a Pringles potato chip can has this diameter (they’re called “crisp tubes” in Britain). I didn’t want to buy Pringles, so I used a cereal box. Here’s my setup before assembly:

Cardboard usually has a way it “likes” to be curled, and one that it resists (creases rather than curls). For this box, the preferred curl is horizontal. So I cut off the tabs at the top and bottom of the box, and curled it by hand a few times, to get the cardboard roughly in the right shape:

Then cut out two of the strips (I chose the input/output strip and the Reflector B), and carefully tape them into bands, put the bands on both ends of the tube, and let it expand, like this:

At this point, I put little tabs of tape inside the tube to help it hold its diameter, and fiddled with it until the bands were able to slide, but also didn’t have any slack. I tacked down the tube with a little tape, and pulled off the bands, then added a full-tube-length of packing tape to the outside-seam, like this:

Finally, wrap the three “rotor” bands around the tube, and tape them, again checking that they can slide around the tube, without being too tight. With the three bands on, add the Input/Output and Reflector B band to the outside-ends of the tubes. Align the grey bars on these bands, and tape them to the tube: they stay put while the rotors move. When you’re done, from left to right, you’ll have the Reflector, Rotor I, Rotor II, Rotor III, then the I/O band. It should look something like this:

Using your paper Enigma

(borrowing heavily from the Franklin Heath wiki – I will rewrite this with my own examples once the book chapter is done)

You can test your basic Enigma now. The “rotor position” part of the key is the letters between the grey bars. In the setup above, the rotor key is FAN. The next aspect of the machine is that each time you encode a character, you first “advance” the rotor, by carefully twisting its band towards you by one letter. Let’s pretend that the key was FAM, and we rotated the right band to make the rotor position FAN. After doing that, take the letter you’re encoding, and locate it on the I/O band on the right, and trace the lines from right to left. In this case, it’s nearly a straight line: A -> N -> A -> G at this point, we’re at the “reflector”, so trace the line on the reflector to see where it leads. It should be W. From there, trace the line back to the I/O band. When I did this, I got W -> I -> S -> K. K is the encrypted version of A. To encrypt the next character, you advance the right ring towards you and repeat the procedure.

With what you know so far, you should be able to decrypt the following message, with the rotors initially set at A B C:

A E F A E  J X X B N  X Y J T Y

If you get that, the rest of the Enigma is just minor tweaks to that process. We’ll go through each of them, because you need to do them all in order to decrypt real Enigma messages (which we’ll do at the end).

Advancing the Rotors

As you advance the right-most ring, eventually you’ll come back to the original configuration. If the Enigma did nothing else, it would be not too different from the Vigenère cipher – not a bad cipher (it was used during the Civil War) – but definitely not strong enough to protect against the codebreakers of the 1900’s. The next (and primary) advance of the Enigma machines was its rotor stepping process. When you are about to advance a band, look at whether the letters are grey in the line between the grey bars on the reflector and I/O bands, and

• if the letter on the middle rotor is shaded grey, turn all three rotors one step towards you,
• otherwise, if the letter on the right-hand rotor is shaded grey, turn the middle and right-hand rotors one step towards you,
• otherwise, turn just the right-hand rotor one step towards you (this is the normal action).

Now the configuration won’t repeat for 26 * 26 * 26 (= 17,576) steps – much better.

To make sure you get it, here are some rotor  position scenarios. When you’re about to rotate, and the rotors are in positions:

• F A V, because V is grey, you would advance both the right-hand and middle rotors toward you, resulting in position F B W
• F E W, because E is gray, you advance all three rotors, resulting in G F X
• G F X, because none of them are grey, only rotate the right-hand rotor, resulting in G F Y

Test your procedure by setting the rotors to A B R, and decrypt the message
M A B E K  G Z X S G

Double-stepping

One tweak to the above procedure (which is, so far, just like a car’s odometer), is that if, after you follow the above procedure, the middle rotor’s grey bar enters the start position, then all three rotors step again. I’m not sure if this is critical to the strength of the Enigma, but doing so is critical to compatibility with real Enigma machines.

You can test whether you understand this part by starting in position B F C, and decoding
R Z F O G  F Y H P L

Rings – changing the turnover points

The next-to-last feature of the Enigma is that which rotor positions trigger turnover could be adjusted. In the real machine, this was done by removing the rotor and moving a pin from one position to another. In our paper Enigma, it’s done by sliding rings over each of the rotors. Each ring covers up the letters underneath it, and its position determines a different configuration of the machine (is part of the message key). Ring positions are described by the position of the ring’s letter A with respect to the letter it covers. Position 1 means that the ring’s A covers the rotor’s letter A, 2 means A covers B, etc. For convenience, here’s a list of which ring letter A needs to cover for each ring setting.

Setting 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Ring A  A B C D E F G H I J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z
 covers

Test whether you’ve got this by setting ring’s I, II and II to 10, 14 and 21. Then turn the rotors to set the message key (on the rings) to X Y Z  and decipher the following message:

Q K T P E  B Z I U K

Pokemon Go and graph theory

Lately I’ve been focusing my efforts on teaching. One thing I’m working on is writing a book about cryptography, math and programming that is targeted at high school-aged students. One of my motivators is equity, so I’m licensing it under a creative commons license, and the source code to the book is here, on github.

Another motivator is enthusiasm – I like to convey my enthusiasm for the material to the students I’m working with. One way to do that is to tap into things they’re already enthusiastic about. For the book, it’s the innate fascination we all have about secret codes.

For this blog post, I’ve got a tidbit about graph theory that is motivated by many folks’ fascination with Pokemon Go. Pokemon Go players do a few different things: they walk around their town collecting items at Pokestops, which are associated with landmarks in the real world:

(image credit: Business Insider)

Some of those items are Pokeballs, which are used to capture the Pokemon creatures that also wander around town. You can evolve and power up the Pokemon you catch to make them more powerful. The reason you care about your Pokemon’s power is that in addition to Pokemon and Pokestops, there are Gymnasiums, which are also associated with real-world landmarks, but instead of having items, they’re places where Pokemon can battle each other. I’ll skip past the part about teams because that’s not relevant, but the part that is relevant is that a Gymnasium can have up to ten different Pokemon in it, and when you battle, you can choose six of your Pokemon collection to fight against the ones in the Gymnasium. The question is: “how do you choose which Pokemon to battle?”

It’s a good question because the designers of the game created complex varieties of Pokemon (e.g., Fire, Grass, Electric, Poison, etc), and a complex hierarchy of strengths and weaknesses among them. So, for example, it’s easy to remember that if you’re going up against a Fire-type Pokemon, that a Water-type Pokemon has a strong advantage. On the other hand, Fire has an advantage against Grass and Ice. It’s a lot like rock-paper-scissors, but with over a dozen types instead of just three. Even more complex than the Big Bang Theory’s rock-paper-scissors-lizard-Spock.

Now we’re up to where Graph Theory can help. Just as this link shows the interactions between rocks, paper, scissors, lizards and Spock: 

In computer science, the above diagram is called a graph. It’s not the same as the graphs we draw of functions, so it’s kind of a confusing name, but you get used to it. These kinds of graphs have nodes and edges. If the edges have arrows, it’s called a directional graph (digraph for short). What this graph tells us is that an arrow from one node to another means that the node “beats” the one it points to.

We’d like a similar diagram for Pokemon Go. It’s subtly different: instead of a simple “Fire beats grass” relationship, we have “Fire is unusually strong against grass”. Even so, this is important information. With a simple cheatsheet like this, we could go up to any Gymnasium with a decent collection of Pokemon, and do serious damage. Also, we could learn which Pokemon we should add to a Gymnasium to make it stronger. So, how to do this?

I started by Googling for “Pokemon Go rock paper scissors” to get a list of the strengths and weaknesses of Pokemon creature types. This list seemed good for my purposes. I don’t know how accurate or authoritative it is, but that’s not as important as what I did with the information. What I could have done is use an art program to draw the graph. The drawback of this approach is that it is very “brittle”, meaning if I want a different layout I have a lot of work to do, or if the data is wrong, I have do a tedious search through the diagram.

What I did instead is use a tool that is designed to take a definition of a graph as its input, and to create pretty drawings of them. The tool I used is called graphviz, and it’s quite powerful and configurable.

The input to graphviz is called a “dot” file (the filenames end in .dot). Here’s my conversion of the above Pokemon database into a dot file:

digraph Battles {
 node [margin=0 fontsize=24 shape=plaintext ]
 # layout=circo
 Fire -> Steel
 Fire -> Bug
 Fire -> Ice
 Fire -> Grass
 Water -> Fire
 Water -> Ground
 Water -> Rock
 Grass -> Water
 Grass -> Ground
 Grass -> Rock
 Electric -> Water
 Electric -> Flying
 Ground -> Fire
 Ground -> Electric
 Ground -> Poison
 Ground -> Rock
 Ground -> Steel
 Rock -> Fire
 Rock -> Ice
 Rock -> Flying
 Rock -> Bug
 Fighting -> Normal
 Fighting -> Ice
 Fighting -> Rock
 Fighting -> Dark
 Fighting -> Steel
 Flying -> Bug
 Flying -> Fighting
 Flying -> Grass
 Ice -> Grass
 Ice -> Ground
 Ice -> Flying
 Ice -> Dragon
 Poison -> Grass
 Poison -> Fairy
 Psychic -> Fighting
 Psychic -> Poison
 Steel -> Fairy
 Steel -> Ice
 Steel -> Rock
 Bug -> Grass
 Bug -> Psychic
 Bug -> Dark
 Dragon -> Dragon
 Fairy -> Fighting
 Fairy -> Dragon
 Fairy -> Dark
 Ghost -> Psychic
 Ghost -> Ghost
 Dark -> Psychic
 Dark -> Ghost
}

It’s really simple: to say that Dark Pokemon are strong against Ghost Pokemon I wrote “Dark -> Ghost” and so on. Then I loaded this file into graphviz (with and without the “#” in front of layout), I got these two images:

Pokemon Go battle strength graph

Same graph, circular layout

 

If you look closely you’ll see they have the same set of relationships, they only differ in how they’re laid out. Pretty cool, huh? So if you encounter a Gymnasium that has a Nidoking (ground/poison), Rapidash (fire), Snorlax (normal) and Gyrados (flying/water) you can use this chart, and know that you could choose a Water, Water, Fighting and Electric Pokemon to defeat them. Note that some Pokemon, like Nidoking, have two types, so you want to choose an opponent that is strong against one or both types, but is not weak against either. In this case, water fills the bill. Water works against fire, then you see that the only thing good against normal is Fighting, and finally electric against flying/water.

A nice follow-on activity, now that we have this graph, is to optimize sequences of Pokemon in Gyms so that it’s as hard as possible to defeat them. You’ll note that our above example had two water-type weaknesses in a row – you’d want to avoid that. After that, you’d like to find, given a set of Pokemon, which ones you can safely trade away, because their strengths are subsumed (dominated in CS-speak) by other Pokemon. And so on — there’s a lot of meat in this graph!

π Day programming activity

In our math club this afternoon, since it’s π day, I’m going to try to lead an activity where we write a program (on the Raspberry Pi, of course) that computes π. The idea I thought of (but we’ll see what the students think of as well) is to use the Monte Carlo method – guess random points (with uniform distribution) in a 2r x 2r square, and compute whether they’re “inCircle” or not (whether the distance from the center of the square <= r). Then use algebra to solve for the unknown quantity π in the formula

π r² / 4r² = inCircle / totalPoints

In my little Python program that does this, it pretty quickly gets to 3.14, but doesn’t get much further. Since these are 4th – 8th graders, I thought I should focus on techniques that have an intuition behind them, so Ramanujan’s fancy equations are out of the question. I’d be keen to hear other suggestions!

Wonderful math educational materials

Speaking of crypto treasure-hunts and math circles…I just found these educational materials from the NSA. There are dozens of lesson plans for topics ranging from probability to geometry. They’re very complete, including clear instructions for the teacher (or parent, or math circle leader for that matter), and nice activities to print out for the students.

Between this, Wolfram’s recent re-dedication to K-12 education, and KenKen, this has been a fruitful month for me in the math education quest.

More broadly, I’ve found the matheducation reddit page to be a very useful place to discover stuff like this.

Read and post comments | Send to a friend

Crypto-treasure hunt birthday party: a great success!

I was surprised to hear Audra wanted “codebreaking” to be the theme of her party this year. Maybe she missed math circle, or maybe there’s cryptography in the air, maybe she knew it would bring Dad even more into the party preparation than normal (last year’s Pirate Party was also

Secret_code_values

a hoot to design).

Codebreaking is pretty abstract, so I knew we’d need something to drive the activity.  Treasure hunts are always fun (for parents and kids), so that seemed a natural combination. Over the days before the party, I thought of the collection of codes and activities we could put together. I knew it would be great to send kids home with something to remember the party by, so I designed a “secret agent ID badge”, and a “Top Secret Code Breakers Manual”. [pdf link]

Sally Browning, one of my friends and colleagues at Galois, had prepared a codebreaking tutorial for some visiting middle-schoolers, and as part of that, she prepared a “scytale” (sounds like s + “Italy”) activity – a bunch of dowels with different diameters, with ribbons to wrap around.  Heidi had found a simple substitution cypher for the invitation (some of our great attendees replied in code — I love it!)  And from there, I pretty much had a template for the activity.

The party started at 1:00. I started working on the final treasure hunt at 8 AM that morning. I finished just in time (!). All told, I think I spent 8 hours working on the treasure hunt activities. As often as possible, I tried to make the activities parallelizable among the 10 guests…this worked mostly, and it was definitely obvious when there was a one-person bottleneck to an activity.

Heidi and I agreed that we’d try to keep the tenor of help provided along the lines of “math circle”, which is pretty much hands-off, but perhaps with a few Socratic questions thrown in to accelerate things if needed.

Here’s the sequence of the treasure hunt:

Audra took a photo of each guest as they arrived.

Top Secret CodeBook

• We put out puzzles and thinking-activities from our “games and puzzles drawer out for people to play with as the party gathered. We also left out a set of the “code books”.
• When everyone assembled, we said “instead of a cake, all we have here is this empty-feeling box”.  Inside the box were two ribbons with letters on them. The kids figured out that dowels would be needed, and thought of wrapping the ribbons around chair legs or other cylinders around the house…not noticing the pile of 10 dowels against a wall.  Eventually, the dowels were discovered, and one ribbon got decoded on the first try — what are the odds?  It took a lot more work to decode the second ribbon. Between the two ribbons, the message was “I have hidden your stuff in a secret location. You will find help where les oeufs are produced.” The two French dictionaries were sitting next to where the empty box started ended up helping out.  “The Chicken coop!” and they were off.
• Inside the coop was a plastic egg with two smaller eggs nested. In that was a tiny USB thumb drive. I created a bunch of directories (A-Z) and a “readme.txt”.  The file said “Look in directory “D” for the next clue”. Inside directory D were another set of directories A-Z, and a readme.txt that said “What “are” you looking for”.  Inside directory “R” was another readme.txt: “what are “you” looking for, again?”.  Inside directory “U” were more directories, and a readme.txt: “mmmmmmmmmmm…I love cake.” Finally, inside directory “M” was a file that said “you’ve found the right place.”
• The innermost directory (note the path was “D/R/U/M”) had a text file with morse code spelling out “The next clue is hidden inside an instrument you hit with your hands.” as well as an .mp3 file with morse code spelling out “DRUM”. I used this web site to generate the two files. The cryptographers broke into two groups, one group tried to decode the audio, the other asked me to print out the morse code for them to decode.  Even though I slowed the morse code audio way down, that team finally switched to decoding the text as well. Nobody noticed the path spelled out DRUM. Interesting!
• Inside the drum was an envelope with a bunch of slips of paper in the original transposition code (I wrote a python program to generate this… see the bottom of this post). I wanted to allow this task to be parallelized, so I wanted to chop up the message into bits, and then added numbers so they’d know which order they went in. The slips decoded to the text “ONE LOOK”, “TWO UNDER”, “THREE THE THING”, “FOUR THAT HANGS”, “FIVE ON ROPE”, “SIX FROM A”, “SEVEN TREE AND”, “EIGHT CHILDREN”, “NINE PLAY ON”, “TEN FOR FUN”.  They quite quickly decoded the individual strips, but had a dickens of a time figuring out the ordering of the slips. They were thinking the numbers were another level of code, or were part of the message, or formed a more complex pattern (like 2 4 6 8 …).  Finally, they got them all on the floor at once, and with a little Socratic questioning help, they figured it out. “The Swing!”
• Under the swing was an envelope with what caused the funniest moment of the party (for me, anyway). I wrote “Hermione shows up with fancy hair and a dress.” With no time at all, the rushed into the house, grabbed the single volume (book four) of the Harry Potter series, and took about 30 seconds to find the right chapter. On that page was another slip of paper, this time with another book title, and a math problem (110 * 3 – 10).  And so on for eight books. The last slip of paper was in an art book, on the page about Miro. They discarded the book before noticing the slip of paper said “look behind a painting that looks like this one.” They dug it back out, found the page, and behind the painting was another envelope, holding a paper saying “four legs eats here”.
• 

  Birthday cake

“Cat bowl!” Under the cat bowl were two more scytale ribbons “Oh, no, not more?!?!”.  They were getting hungry for cake.  The scytale ribbons had a little-bit-too obscure clue (I think I was getting tired at this point in the puzzle-making process): Ribbon one: “Your next clue is hidden inside a musical instrument on the West wall of the house” and “If you go to Hawaii you will hear my strings”. It took way too long to find the Ukelele on the West wall of the house. I was busy upstairs laminating the ID cards, but heard the excitement of finding a slip of paper with the URL http://www.cheapimpostor.com/mecodegoodsomeday/secretCode. Heidi says she had to help them with the typing – theirs was too error-prone to get it right.

• They recognized bits of the car, and my car-key’s bike-chain keyring. They finally found the cake in the trunk…but no goodie bags!  Fortunately, the icing had morse code (“Not again!”) that said “look under the bed” which is where they found their goodie bags.

Heidi heard more than one guest say “this is the best birthday party ever!” which blew me away, but totally reinforced the theme of a book I’ve been reading (

Theory of Fun for Game Design

A Theory of Fun for Game Design, by Ralph Koster), which is that real “Fun” comes from the excitement of actually learning something new.

All told, it took 2.5 hours to solve the clues, and they just got to the cake as parents arrived to pick them up. It was an exhausting, but very rewarding, party.

As an aside, here’s the shell script I used to create the maze-on-thumbdrive (watch out – it’s slow, and the result takes up a lot of space!):

#!/bin/sh

export digits=”A B C D E F G H I J K L M N O P Q R S T U V W X Y Z”

for i  in $digits; do

mkdir $i

cd $i

cp /tmp/readme.txt .

        for j in $digits; do

                mkdir $j

cd $j

cp /tmp/readme.txt .

        for k in $digits; do

mkdir $k

cd $k

cp /tmp/readme.txt .

        for l in $digits; do

mkdir $l

cd $l

cp /tmp/readme.txt .

cd ..

done

cd ..

done

cd ..

        done

cd ..

done

Read and post comments | Send to a friend

Fall 2007 math circle concludes

It’s been too long since I updated the blog with math circle news…quite a lot has happened:

Binary arithmetic

We did two days on binary numbers.  Five students sat at the front of the room, each holding a card with dots. From the right, moving left, the first card had one dot, the second two dots, the third four dots, and so on.

I asked the students how to make the number Ten by selecting cards.  I told them that the new way to say the number Ten was to name the students who were holding up cards. To make things clear, we said the names from left to right, and if a card was being left out, we said “blank” instead of the name.

We named a bunch of numbers in English, and translated them to “math circle-ese”.  This was great.

We then took turns adding one to different numbers, which was also great.  Then we ran out of time.

The next week, a few students showed up who hadn’t been there the week before, so we reviewed the activity, then we moved on to adding two different binary numbers.  The big trick here is carrying, but quite a few students got it. Unfortunately, I think we went too fast for some, and I wasn’t able to take the time to bring them back into the fold.

Probability

The next week I brought two dice for each student, and sheets of paper with number grids from 1-6 and 2-12.  We all rolled first one die, then two dice, filling in a square each time a number (or sum) was rolled.  I was amazed at the distributions.  Finally we all reported our 2-12 sums to the front of the room and added those up. 8 won by a landslide, but 7 & 6 came in 2nd and 3rd.  Interesting!  Everybody enjoyed the activity, but I think the summing felt “forced”, so the learning wasn’t as effective.  This could have easily been spread out over two or three sessions with lots of discussion and less dice-rolling.

Snowflakes

The next week we made paper snowflakes, and discussed the math of the activity.  We talked about reflection, as well as “how many diamonds will my snowflake have if I fold my paper X many times and cut one diamond?”  Some of the students delighted in the fact that this pattern brought back our binary numbers (woohoo!).  If we had more time, and enthusiasm, it would have been good to bring everybody along for this, but the energy in the room was very scattered.

Code

Finally, yesterday I brought in a code (with key) for the students to decode.  This was wonderful. The energy was subdued but interested. (Interestingly, a number of the students proposed they read instead of do math circle.  I said that’s fine, please do it at a table behind the others.  Very quickly that whole table was engrossed in decoding the message. Neat!)  Once the students finished this, I suggested they encode messages, and a number of them wrote long messages and handed them to me to decode.  I showed them a quick way of decoding using a tree (left is “.”, right is “-“). None of them thought it was faster (hmmmm.)  I was flattered by the messages they sent me. Thanks! 🙂  I finally told them this was Morse code, but not before Madi called it “binary code”.  Cool.

What’s next?

I’m going to ask the parents to send me frank evaluations of what went well, and what didn’t (both from their perspective and to ask the students).  I’m planning on doing something in the Winter or at least by Spring, but it won’t be exactly the same. I’d like to have fewer students per group, but figure out how to do multiple groups. So my work moving forward will probably be more volunteer coordination than direct student interaction. This is both sad and happy for me (less directly fun, but more impact).

Read and post comments | Send to a friend

Math circle! (weeks 2 and 3)

We’ve had two more math circle sessions, and I (at least) enjoyed both of them quite a bit.  The second session (which was really the first official session), I slightly repurposed an activity from “computer science unplugged”.  We took turns being, and then programming, “Drawbots”. Initially we started with blank paper, and had the drawbot face away from the whiteboard, and the programmers face toward the whiteboard (but sitting on their hands).  Then I drew various figures on the board, and the programmers described to the drawbots how to reproduce the figures using only words.

It was a hoot.  I started with simple drawings: a rectangle with an inset square with an inset circle, and similar arrangements.  Then (warning them I was doing to do something difficult), I drew two parallel wavy lines.  Hilarity and mayhem ensued.  One student was so frustrated, she started to cry. I assured them all that mistakes and frustration were the point of the exercise – that made her smile and she quickly recovered. (whew!)

Next I brought out some numbered graph paper, and had them draw points at specific coordinates and connect the dots to draw shapes.  We did a triangle, then a simple face.  I made a mistake transcribing the numbers to the whiteboard, which cracked the kids up.

The following Monday, as Heidi was dropping Audra off to class, a number of parents said how much fun their child had in Math Circle, and how they were disappointed there was no homework over the weekend. (woohoo!)  So I drew one up and sent it out. As part of it, I wrote a program that plotted the homework to make sure I didn’t make any mistakes (actually, so I knew where the mistakes were).

MathCircleNumberMachine

There was a week off, followed by this most recent meeting on Nov. 2nd. I decided to finally do some non-robot, mathlike exercises.  I read the activity name “function machine” in the math circles book by Bob and Ellen Kaplan, and decided to design what it would be myself:  I brought some empty cereal boxes and cut slots in them, and labeled one “input”, the other “output”.  Once the group had settled down, I told them that this “number machine” took slips of paper with numbers on them, did something to the paper, and spits it out the output slot.

I started by being f(x)=x+2, then f(x)=2x.  It was hilarious!  The kids were really excited at first just to go through the process, shortly after when they realized the output was related to the input, and finally when they figured out the relationship between the input and the output. Next I tried f(x)=x/2.  I knew I was out on a limb with this one…I got a 2, a 4, a 3 (1 1/2!), and at 10, everyone guessed correctly using different language than I’d have guessed – “Takes away half!”

Then we broke into groups of 4 or fewer, each with a parent volunteer (thanks!!). They first decorated their own number machines (this was a good break in the pace), then took turns being functions. The kids did great.  It was amazing to see the excitement when they thought they had the answer, and sent in a number to test their hypothesis. When it was my turn, I did f(x) = 2x+1, and they were vexed.  I could tell when they were frustrated with something when the numbers I got were over 20.  10,000 isn’t going to tell you much about a number machine’s function that 0 or 5 wouldn’t.  At that point, I suggested thinking about what a “doubler” machine would return.  After four more tries, one girl got it, and was thrilled when she turned out to be right.  I hope that wasn’t too much of a hint.  Given the chaos of the moment, I don’t think a subtler hint would have gotten through.

For homework,  I’m going to try doing some number machine activities around the breakfast routine for a while.  Colin (our 4-year-old) likes participating just to see the machine do things.  Generally his numbers have four or more digits. Awww.

Anyway, this has turned out to be a wonderful experience for me — all of the kids seem to truly light up.  I’ve got two weeks to come up with a good follow-on activity.

Read and post comments | Send to a friend

Math Circle!

As I say on my web page, I really care about education. In addition to thinking about how to fix things nationwide, I’ve decided to do something at my daughter’s elementary school. I’m starting a “math circle” that meets after school once a week through the end of the year.

We had our first meeting on October 5th — it was a blast! I originally planned the meeting to be a parent/volunteer orientation, but decided to have it be a parent/volunteer/kid “kick-off”. To really get things off to a good start, I decided to do a really fun activity I’d done with Audra last summer: programming robots. Not lego robots, not erector-set robots, but instead, the most sophisticated robots known to mankind: people! We talked about what programs were (kind of like recipes, but for doing things besides cooking), and talked about how hard it is to describe, in detail, how to do things, like play soccer or dance, or whatever.

Then we broke into teams of 4-5 kids (3 groups!) and each group decided what they were going to do, and who would be the robot. After about 30 minutes of wonderfully noisy hilarity, we showed each other our programming prowess, and the results were very gratifying. Kid-robots were walking around the room, picking things up, drawing on the whiteboard, and so on. Different groups chose different levels of abstraction for the instructions, but that’s just fine: this math circle thing allows the kids to set the rules. The adult facilitators are there mostly to make sure the kids follow the rules they’ve set for themselves.

Next week we may delve a bit deeper into this topic again (loops, if/then/else, and procedures for sure, maybe (just maybe) recursion, etc. And after that we’ll move towards things that seem more classically like math. I think we have their attention, though!

Read and post comments | Send to a friend