We all know that multiplying by 2 repeatedly gives powers of two, as: 2, 4, 8, 16, … And if you keep dividing by two, the rational representation is, unsurprisingly, the inverse, as: 1/2, 1/4, 1/8, 1/16, …. Leo noticed that the decimal representation of these progressive divisions by 2 seem to be powers of 5, not 2, as: 0.5, 0.25, 0.125, 0.0625, and that in order to get decimal equivalents of the increasing powers of 2 (2, 4, 8,…) you have to divide by 5, not by 2 as: 1/5=0.2, /5=0.04, /5=0.008, /5=0.0016, etc!

A moment’s thought will reveal this to be not very surprising, as 2 and 5 are inextricably bound together in base 10 arithmetic (because 10 = 2*5). So, even though the mathematical reason for this is obvious (after a moment’s thought), it remains slightly weird that 2, 4, 8, … are the same as 2.0, 4.0, 8.0, …. but 1/2, 1/4, and 1/8, … are 0.5, 0.25, 0.125, …. Put even more starkly: 2/1, 4/1 , 8/1, … invert naturally to 1/2, 1/4, 1/8, … but the decimal representations don’t “invert” in the same easy way: 2.0 -> 0.5, 4.0 -> 0.25, 8.0 -> 0.125, …. My friend, Eric, notes that: “Dividing by 2 is like multiplying by 5 and dividing by 10. Hence the successive powers of 5 and convenient shifting of the decimal point.” This just re-emphasizes the fact that rational representations (i.e., fractions, as 2/1 and 1/2) are very different than decimal, place-value representations; they just work differently is all there is to it, regardless of the faux amis of 2.0 (that is, decimal 2.0) and 2 (i.e., the number 2), and our short hand for rationals with unit denominator (as: 2/1 => 2) having similar looking overt.

Continued thoughts: Fractions (rational notation, as in 2=2/1=10/5, etc.) isn’t place-value! The separate components (numerator and denominator) are place value, but the whole thing isn’t! This leads to the weird effect that if you keep dividing by 2 from, say, 4, you get a nice balanced progressions: 4, 2, 1, 1/2, 1/4, and so on, whereas when you divide place-value notation by 2s you get 4.0, 2.0, 1.0, 0.5, 0.25, etc. The former (rational — fractional) notation is really just multiplying the denominator by 2 (i.e., dividing by 2), so the above sequence could, more obviously, be written: 4/1, 4/2, 4/4, 4/8, 4/16, etc. (you could, of course, start anywhere you wanted: 8/1, etc.). You can do the same trick in decimal notation by multiplying by, say, 1000: 8000, 4000, 2000, 1000, 500, 250, 125, etc. That looks a lot less odd, and you can see that it becomes “5-ish” when you have to divide what is an odd number: 1!

Leo watched an extremely good TedEd about sorting algorithms, and wanted to try it out himself, so we wrote a simple bubble sort in Python, and we deployed it through the PythonCraft API to run in MineCraft. This turned out to be more fun and educational than I thought it was going to be.

To begin with, here’s the code (slightly cleaned up for display here; you’ll have to add the right imports, for example):

Unsurprisingly, we had the longest discussion about why you need the “Hold” variable in the swap step(s). There are two errors in this code, that I’ll reveal below. (The highly motivated reader can try to figure these out; Actually, any semi-competent programmer can probably guess what the errors are without even looking at the code!) Regardless, it does the basic job.

So, it’s actually extremely cool when it runs, because you can watch the sort in action, and actually chase down the sort front! Here are a couple of videos of us doing that:

(Note the sheep on the blocks!)

You can see (and I mention) one of the bugs in the video: The “Obi wan” (Off by One) error, which leaves on of the blocks unsorted at the far end of the array.

The other bug is more subtle, until I point it out: We actually intended to sort by rainbow order (ROYGBIV), but that would have required another dereference, and when I tried to explain that, it went right over Leo’s head, him already being well snowed by the Hold/Swap problem, so I simply let it go. As a result, it’s actually sorting by whatever the color codes happen to be in MineCraft, which seem to be random (or at least I can’t tell what the logic is that relates MC color IDs to rainbow order).

Leo’s FLG (Focused Learning Goal) for this year is to build a real quantum computing mod in MineCraft. (Note that the kids set these goals for themselves at the beginning of the year, and although I might have slightly influenced his choice of project, the “in MinceCraft” setting was all Leo!) This came from several sources, aside from just the obvious entanglement of his interest in quantum computers with MineCraft. The main one is that there are two quite cool MineCraft mods, one, called qCraft, that adds a sort of quasi-quantum mechanics, and another, called Mekanism, that adds all sorts of advanced devices, esp. lasers. The qCraft mod actually has quantum computer components, but they are not very elegantly done; We wanted to make it a little more like a real quantum computer by using the Mekanism lasers as the qubit sources, and then add optical components for the gates.

Anyway, so we needed to get our feet a tiny bit wet toward this pretty massively complex FLG. Unfortunately, direct MineCraft modding is done either in Java or Python. (There are a few little experiments in modding in scratch-like languages, but, much as they are nice tries, they have issues, so I decided not to bother with them, at least for the moment.)

The circle represents a qubit that might be a photon, for example, and its color represents its quantum state: green is definite 1, and red is definite 0. It travels a continuous loop from left to right, and then re-appears on the left again, as though it’s on a quantum wire that’s looped around from the end to the start.

When the program starts, the photon’s quantum state is definite 1 (1.0|1>+0.0|0>), and so the photon is green. The M box on the right measures the quantum state, “collapsing” it to 1 or 0. If you just let the program run from the start without doing anything (as above), the measurement gate will just keep reading 1, and incrementing the 1 count. The photon will just stay green.

The hex is a Hadamard gate (H gate), which splits the quantum state in half: 0.5|1>+0.5|0>. (Remember that we’re simplifying here, so there are no complex values or normalizations, and I’m using probabilities instead of amplitudes; I did say “simplified” and “baby steps”, right?!) If you drag the hex into the photon’s path (pic below), the state becomes a mixture of 1 and 0, and the color becomes a (ugly) mixture of red and green:

When the qubit in this 50/50 state gets measured (that is, when it hits the M gate), there’s a 50/50 chance of “collapsing” into a 1 or a 0. It’ll change to either red or green, start again at the left, hit the H gate again, and so on. If you let it run like that for a while, the counts of 1 and 0 will come out the same, statistically speaking.

(Unlike most of the work described on this blog, the work described in this post is mostly my own; Leo only participated as a willing player of the resulting game, and in a tiny bit of programming at the end.)

I’ve been trying for some time to get Leo to understand Turing Machines. I had high hopes for MineCraft Turing Machines that Leo found utterly fascinating … as did I! (There are some amazing videos of MineCraft Turing Machines out on YouTube!) And we’ve had a couple of iPad apps that are slightly helpful, but they aren’t really engaging enough for a seven year old. I had the idea of creating a Turing Machine mystery game, where you have to figure out what the program is doing, and I finally got around to programming it.

Because we’ve mostly been doing our collaborative programming in HopScotch, which Leo really like, I figured I’d try to make the game I’d imagined there. Unfortunately, There are many issues — such as timing problems, lack of local variables, and non-independence of cloned objects — that made HopScotch is a little too simple to make anything very complex. (Although some HopScotchers have done amazing things! Sort of like the MineCrafters building computers (and Turing Machines!) out of RedStone!) However, with a tiny bit of clever design, and a great deal of trial-and-error mucking about, I finally managed to get a simple version of the game I’d envisioned to work, and Leo actually liked it and played it!

Here are a couple of screencaps from the game in progress. By tapping on the circles, you toggle them center/up/down, and then you can start the machine, which pushes the robot on the left one cell to the right, which starts it executing The Rule. The lower picture, below, shows the state after the machine has stopped from some starting point that I don’t remember.

And here’s the rule, which is coded inside the custom function: “Execute the Rule”(Y Nil means that the circles are centered — poor choice of names!):

Leo got the idea of the game right away, and actually mostly figured out the rule by the intended game play. Then we tried to modify the rule, and although he knew what he wanted to do, which means that he got the concept (Success!), actually making the right changes to the rule case took a little collaborative programming. (My poorly chosen names, like Nil, didn’t help things!)

[It slightly bothers me that the last few posts are mostly MineCraft-related. But as Leo has been getting more and more interested in nuances of MineCraft, I’m trying to guide this interest toward math instead of evil. (And “evil” is MineCraft is quite a lot less evil than with many other things he could be getting addicted to.) (Some day I’ll talk about MineCraft addiction management strategies … when I figure some out!)]

Interestingly, in MineCraft, the term “seed” makes for a convenient pun; Leo understood perfectly that the “seed” is what the world is grown from. But in reality, of course, is comes from the concept of a random number seed, which is how the pseudo-random number generator uses to create the random stream that starts off the whole world, and everything in it. This, of course, is how it’s possible to publish the seed, as in the web page above, and others can get back to the same exact (initial) world.

So I turned this into a lesson plan on random numbers, pseudo-random numbers, determinism and non-determinism, and one of Leo’s favorite topics: Quantum Computing and cryptography.

Leo got right away that 4+5 is determistic, and if you were to print the result in a loop (bottom right scribble) you’d get 9 every time, but 4+Rand(10) would randomly give you a number between 5 and 14. (I’m using 1-origin — someday I’ll go into that with Leo … actually, I may have already at some point.) Note, also at the bottom left the important observation that “All non-quantum computers are DETERMINISTIC.”

So, the mystery is:

To translate my scribbles:

All (non-quantum) computers are deterministic.

Rand(#) [which is a computer function] seems to be non-deterministic. (We tried this on the iPad in the BASIC interpreter.)

The mystery (apparent paradox!) is: How does Rand work? (We had a brief passing philosophical discussion about paradox v. conundrum.)

The answer, of course, is:

PSEUDO-RANDOMIZATION – Ensued a long interesting discussion of possible pseudo-randomization algorithms, the meaning of “Mod” (the modulo wheel at the bottom center), and so forth. (This board had lots of erasures; You’re only seeing the end product!)

The key concept, which closes the loop on MineCraft seeds, is that the computer needs to have something external in order to seed the pseudo-randomization. That’s what the box around MineCraft is. We talked a lot about where the computer could get a seed. One place is obviously that you give it a specific seed. In that case what’s external is you! But what about when you don’t give it a seed? (Leo’s initial solution, of course, was to use Rand() … 🙂 After explaining why this wasn’t going to work (can you say: “infinite regress”?) And quantum fluctuations, I posed the following problem: Suppose that you were locked in the kitchen with all the lights off at night (we actually did this exercise, of course), and needed a pseudo-random seed…. It only took a few seconds to get the right answer to this one:

Given Leo’s love of large numbers, it’ not surprising that he is fascinated by what’s called The Farlands, at the edges of the Minecraft world. Basically, The Farlands are some combination of (a) the limits of the internal Minecraft representation, (b) places where, presumably for the sake of speed, the engineers just populated the world with random numbers instead of bothering to create topography where most players will never see it, and (c) bugs. The bugs are likewise in places where most players will never get to, so who cares, right? Answer: Pretty much every young nerd like Leo cares!

So, per my usual theory of making everything a math or science lesson, we use the Farlands as a way into a lesson about computer math. Here’s our whiteboard:

Without trying to annotate everything on the board, we were calculating how many bits it would take to represent the XZ coordinate limits for Minecraft. (Minecraft uses Y for the vertical access, which seems slightly weird if you’re trying to navigate the map because you’re looking down on it, but it’s this is way that it’s usually done in physics.)

We imagined maps of various sizes, for example: 128×128 (on the left about the middle of the board), and then tried to figure out how many bits we’d need to represent these, which led to a short lesson in base 2 logarithms. The interesting thing that Leo noticed, and which was what initiated this lesson, was this seemingly weird factoid from the Farlands web page:

Leo thought that that number was really funny and weird, but I thought that I knew why that number was like it was — specifically, that’s 2^64th. So we talked about binary representation of number (which Leo already knew from long ago) and logarithms as a way to figure out what power of 2 you needed to make a given value, and did some examples, and then used Wolfram Alpha to test my hypothesis that 9,223,372,036,etc is 2^64th:

Um….oops! I forgot that that’s actually the positive limit, but the world is actually TWICE that, positive AND negative!

This led to more lesson on binary representation of positive and negative numbers, and how you could do it with a single sign bit, and the “correct” representation where (in three bits) -1 = 111, -2=110, and so on. This is the stuff on the upper left of the whiteboard. Leo himself noticed that it would wrap around at 4 = -4, and asked why Minecraft didn’t wrap around at 2^63+1…Good question. That would be cool!

I’ll eventually write a long series of posts on Minecraft, but for the moment, I’m going to start at the end, because, well, we got to the end game a little earlier than one normally would.

The reasons that we got to the End Game are that, first, ever since we’ve been doing Minecraft, which isn’t actually very long (although it’s a long story, for another time), Leo has been obsessively studying, and obsessively telling me all about, the End Game. In the Minecraft end game you: Discover a Stronghold, Find an End Portal, Get into the Ender World (or whatever it’s called), Kill the Ender Dragon, and Solve a slightly complex mechanical puzzle, all while trying not to die in various stupid ways that you can die in Minecraft. Once you’ve done all this you’ve basically won Minecraft, and are reworded with an actually quite moving and lovely (albeit long) poem. I was hoping that by going through this with Leo I would be rewarded by his no longer bothering me about all this…. (We’ll see!)

So, anyway, in keeping with my theory of math education, where everything fun is mathematical, and everything mathematical is fun, we turned the search for the Stronghold into a math problem, which is described by the scribbling on this whiteboard:

To make a long story short, the Strongholds are randomly located slightly underground along three axes 120 degrees apart at between 640 and 1550 (or so) blocks from the world center. In order to find them efficiently, you can thrown an “Eye of the Ender” up in the air, and it travels for a bit in the direction of one of the Strongholds.

Finding the stronghold along a given line is analogous to the children’s game where someone thinks of a number in a range, say 1-100, and then the magician asks if it’s say, 50, and if not, whether it’s higher or lower, at which point you go to 1/2 way between (25, for lower, for example).

In mathematics, this is approximately Newton’s Method — or at least I always think of Newton’s Method when I think of this game. In algorithms design it’s called binary search, and it’s easy to prove that it’s big-O log-base-2 in the size of the ordered list, so, in the case of 100, it’s O(Log2(100)) or about 6-7 tries, max.

Leo and I calculated all this, and figured out where the middle of the line connecting the center (where we started out) between 640 and 1550 was. (That’s what all the trig is in the picture above — the line wasn’t exactly along the X or Y axis, so there’s some complexity.)

And then we started to search for the Stronghold, and lo-and-behold, it worked! In about 5 tosses of the Eye of The Ender we hit pay-dirt (literally — well, digitally, anyway), and upon drilling into the ground where we ended up, found a stronghold, played the end game, and won!

Now that he’s won, let’s see if Leo will come down from his Minecraft addiction! I have low hopes; He’s already made a list of the numerous other Minecraft challenges he wants to solve.

Leo has had a couple of bouts with video game addiction, which we pretty actively stomp on, but it doesn’t make any of us happy to have to ruin his excitement, even if it is about something completely stupid. Last year in the JCC after school program he was exposed to Plants v. Zombie, and since then it has come up on occasion as something he wants to play. Recently, in a moment of stupidity, I gave in and got him the iPad PvZ2 game. Unfortunately, he was immediately hooked — like when crack addition is depicted on TV! — so that all he thought about, spoke about, depicted in his drawings, etc. was PvZ.

Now, PvZ isn’t the worst game in the world; it’s pretty clever, and at least it’s not shooting people with guns and having their blood splatter all over! But the level of addiction that Leo exhibited was hard to control, and when we tried taking it away he would become quite emotional. We would have ended up taking it away anyway, but instead I decide to try to redirect his interest into something slightly educational, to wit:

DICE versus ICOSAHEDRA (1)

To make a long story short, we invented a dice-based analog to PvZ that has pretty much the same strategy components, but with a whole lotta ‘rithmetic (and some probability) along the way! Moreover, this game is interactive, so kids can play it together, or you can play it with your kids.

(I even convinced Leo to write-out the instructions quasi-neatly!)

The basic idea is that you get one of those large random die collections, which are cheap, and actually fun in-and-of themselves. (Every home should have at least 50 random die!) The zombies are played by icosahedral die. A standard 6-sided die is the zombie creator. The plants are played in various complex ways by the other various-shaped die (see below). The sun (which is the giver of points to grow new plants) is also a die (ten-sided works well, preferably with 00 10 20 …), and so on.

[The game in some random state of play: Energy score pad to the left. Sun is the yellow transparent die top right. “Lawn mowers” are the playing-card dice on the left margin of the field. Plants are purchased from the top row — ex. “PS” = Pea Shooter” (costs 40 energy) — When a plant is purchased and placed, a new one of that type takes the old one’s place at the top row. The green die next to the sun is a sun flower (SF). I think that this multiplies the energy you get from the sun … or something. I have to admit that I wasn’t quite clear on the slightly random rules that Leo made up for the various plants! Right side is the zombie creator die (white 6-sided) and several waiting zombies (icosahedra). There’s also a pea shooter there (for an unknown reason).]

The rules we ended up with were slightly random, aside from the principle that the larger the number of sides on the plant-die, the more powerful, and of course more expensive, the plant.

Game play is in four phases:

Create or move zombies. Roll the zombie creator (6-sides). 1-3 any zombies already on the board move (person playing the zombies can distribute the movement as desired). 4-6 a new zombie is created: Roll the chosen zombie (icos die) to assign that zombie’s health level and place it on the board. If there are no more zombies that can be placed, when the last zombie is removed from the board, the gardener wins.

Roll sun and plant player (aka. gardener) collects energy from the sun.

Gardener buys and plant plants, subtracting from energy in the obvious way.

Plants attack. The specifics of attack mechanics is different for each plant. For example, the PvZ Pea Shooters are played by 4-sided pyramidal dice, which are simply rolled and then the sum score is distributed subtractively among the zombies on that row, as desired by the gardner. And so on. Any zombie that reaches zero is removed from the board. Usual rules apply for zombies that reach the gardner’s side: First one gets run over by the lawn mower, after that zombies win.

That’s about it. You can make it as simple or complex as desired by modifying the plant rules. For example, our game had a black six-sided (standard) die that stood in for fertilizer. It was pretty expensive, but it multiplied the strength of a plant attack, so that if the plant roll was, say, a 4, and the fertilizer roll a 5, then the total attack was 20. You can expand upon the rules as desired to push the players into more and more complex math.

Leo’s math specialist showed us some examples of a game that they play in math pullouts. Basically, you have to figure out the values of each letter, based on a table of total values for names made up from those letters. Here’s the table:

My initial reaction was that this is ridiculously difficult; you’d have to solve 30 simultaneous linear equations. But after staring at it for a few moments, you’ll notice that some of the names are really weirdly spelled, like “KOLE”, for example. In short order this will lead to the discovery that actually makes the puzzle pretty easy. Specifically, notice that some of the names are exactly one letter away from one another, for example LEO and KOLE (which is why KOLE is spelled weirdly), so the value of the differing letter (K), must equal the numerical difference between these two names(249-242 = 7); that is: LEO=242 and KOLE=249, so K = (249-242) = 7. Once you discover this trick, you can find many of the letters by simple subtraction, and then you can get the rest by substitution into the longer names. Once I had this insight, it took me about 20 minutes to solve the whole thing by hand. (Including making a bunch of stupid errors!)

Okay, so that’s a sort of vaguely interesting math puzzle.

(Note added 2015-10-26: I can’t decide whether I believe that the “trick” of noticing that some of the names are one-off from one another is useful, or just stupid, like one of those stupid trick questions…”Ha Ha It’s an electric train so there is no smoke!” It’s sort of interesting to let the kids try out various things, like putting the names in numerical order, which is how I noticed the trick…but (a) it’s hard enough even when you know the trick, and (b) if you don’t get the trick, it’s REALLY hard. So I can see that some kids might get very frustrated if they never happen upon the trick. Anyway…)

What I don’t quite get it why didn’t they do the obvious STEM thing and use molecular (molar) weights instead of random names?

Towards this end, I wrote a program that took a list of rounded atomic weights — from here on, all inputs and calculations are rounded to the nearest integer — and formulas for common compounds, and figured out the (rounded) formula molar weights by summing the (rounded) atomic weights. Given that, all you need to do is find all the off-by-one-element neighbors.

From the above (actually, from the complete list of neighbors that the program produces), it’s easy enough to create a STEMyfied version of the names puzzle that would actually teach a little something about chemistry.

The game has two players, and each has 5 keys representing the first 5 primes: 2,3,5,7,11 on opposite sides of the screen. Here’s the layout (we didn’t take enormous care placing things, so it looks slightly random — future detailing):

The number in the middle (28 on this round) is falling slowly — which you can’t see, but below you’ll see it at various states of progress. As the instruction text says: Each time one player or the other clicks on one of their keys, the number in the middle is divided by the number clicked. (The instruction text vanishes after 10 seconds.) Also, the player who clicked the divisor gets 5 points added to his or her score. (The scores, once there are numbers, replace the “Left” and “Right” texts. You’ll see this below.)

In the depicted case, for example, if the left player clicks, say, 2, he (I’ll use he because both Leo and I are guys) will get 5 points added to his score, and the number will be divided by 2, which will make it 14. It continues to fall, and if you were to leave it at 14, when it hits the red target, BOTH players will get 14 subtracted from their scores. But if the players continue to divide the number, say by 7 leaving 2, and then by 2, leaving 1, then the round ends and BOTH players get 50 points.

Here are the game in slightly later stages of a different round. The initial value was 147:

Looks like the left player clicked 7, which divided the number by 7, to make it 21, and the left player got 5 points:

The round would continue, either with a 3 and a 7, in which case both players would get 50 points (and the players who clicked the 3 and 7 would get 5 for each click), or, of they didn’t get it all the way to 1, and it hit the target, they’d both lose 100 points!

Now, you might well ask: What happens if you choose an uneven divisor, like suppose that instead of a 3 or 7, you clicked 5 for 21, which would end up with 21/5, or 4.2?!

For example (this obviously is a much later round):

Okay, so now the players are hosed! There’s no way to get to 1 by dividing a non-integer by integers. When we originally designed the game, we were going to disallow this, and ding a player who tried to do it by some number of points. Unfortunately, this turned out to be extremely hard to program, because Hopscotch doesn’t have a Truncate function, so it’s actually pretty hard to figure out whether one number is a divisor of another. (You would normally just see if Truncate(N/d)=N/d, which is easy, unless you don’t have a Truncate function!)

We tried to find a satisfactory work-around for this. Turns out that you can actually implement Truncate in Hopscotch by successively subtracting 1, until you reach a number less than 1, which must be the decimal part, and then just subtract that from the original number. This actually works, but it’s way too slow to be useful.

So, we gave in to having decimal numbers. But this turned out to be a blessing in disguise, because it makes the game MUCH more interesting. How so? Well, we added a rule that if the number hits the target at less then 1 — which it must do if you keep dividing over and over), for example:

then BOTH players lose 100 points. So it’s really really bad to over-divide. This rule discourages the players from just randomly clicking numbers to try to divide the value down to 1, because if you end up below, you both get docked 100 points! At the same time, if you do end up making a mistake, as in whatever it was that gave them 10.5, above then the way the rules are encourages you to try to divide it out to just over 1.0, but not below, so that you get dinged the minimum. For example, if these players just left the 10.5 to hit the target, they’d get dinged 10.5, but if they did a 7 division, it would go to 10.5/7, which is 1.5, which is a lot less of a ding. But they have to be careful not to go beyond 1.5 to less than 1, nor could they have used 11 from 10.5, because that would have put them at 10.5/11 = 0.954545…, which, being under 1, would have cost them both 100 points!

So by virtue of not having Truncate available, the game actually got to be much more interesting!

A couple of notes about programming. We wanted to make sure that we never ended up at a prime number, either as the original number, or as a factor >11, which the players wouldn’t be able to make into 1 under any circumstances — that is, there would be no solution (although this is actually made moot by the fractional rules described above, since they could just divide it down as closet to, but above, 1 as they could get). So instead of just picking a random number, we did this complex thing, which creates the initial value by multiplication of 2s, 3s, 5s, 7s, and 11s:

The other thing worth a tiny bit of description is the scoring function, which is slightly interesting (to non-programmers) in that it uses a simplifying interim value (delta):

The above sets Delta according to the scoring rules, and then the latter part of the below actually does the score updating:

(The above two pieces of code go together; I just wasn’t able to put them in the same screenshot; Note that they overlap by a few lines of code.)