HopScotching towards Quantum Computing


, , , , ,

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.

(If you don’t know what the heck I’m talking about, there are innumerable videos on quantum computation on youtube, but if you REALLY want to understand it, I strongly recommend this excellent set of short lectures by Michael Nielsen, which not only nicely demystifies quantum computers, but at the same time demystifies quantum mechanics!)

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.)

To get our feet wet using a programming paradigm that Leo already knows, we chose HopScotch. Together we created a highly simplified quantum computer game in HopScotch. We only have one gate, a Hadamard gate, and the quantum state is highly simplified, having only the possibilities of being 1 or 0 or 50/50, no complex numbers nor normalizations.

But it’s kinda cool, none-the-less:


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.

You can try it out yourself on HopScotch on your iPad. (I’m told that HopScotch now allows you to run code in your browser, so you don’t need to actually have HopScotch on an iPad, although I highly recommend HopScotch on an iPad!)


Some pointless Pi/factorial numerology


, , ,

As I’ve previously mentioned, Leo loves large numbers. While we were looking at factorials with huge numbers of digits in the result — a favorite puzzle being predicting the number of trailing zeros — he noticed that there were a few digits of Pi embedded in one of them. So we wrote a program to find the largest run of Pi embedded in a factorial…or at least as far as we felt like letting the program run, which was up to 26000!

Here’s the log:

Pi digs  n(!)
1          8
2         32
3         35
4        116
5        147
6        380
7       3057
8       5599
9      14192

That’s it under 26000! I’ll spare you the 52765 digits of 14192! Suffice it to say that the sequence “314159265″ shows up at the 48996-th digit!

(Before you complain, of course there are many occurrences of shorter sequences all over the place. This is just the location of the first occurrence of each next longest subsequence, so, for example, there are 3, and 31, and 314’s all over the place, but the first 314 occurs in 35!)

I’m not going to bother showing you the couple of line of simple Lisp code that it took to program this up. …Exercise for the reader!   🙂

An Exploration of Molecular Rigidity


, ,

As I mentioned a few posts ago, Leo and I have started receiving Science Magazine, and each week, in addition to paging through the issue looking at interesting pictures, I try to find something that we can actually do together that is related to one of the papers (even if the relationship is tenuous).

This week Leo became interested in this paper:


Okay, so I’ll admit that, not only didn’t we actually read the paper, but I can only vaguely understand the abstract! However, what attracted our attention was this cool figure:


Leo has always liked complex molecular structures; since he was three, or so, he’s had a molecular construction kit, so these looked like fun!

What seemed most interesting about these molecules is that some of the structures appear to be rigid, while others appear to be floppy. Molecule 2.2, for example, seems to be floppy, whereas the 4.x structures (and 2.1) appear to be rigid.

Whether or not this ends up being really true (recall that we didn’t actually read the paper — see “tenuous” above! :-)), it’s a great excuse to explore rigid v. floppy structures, which we did!

It turns out to be surprising, and surprisingly simple to build structures that can be easily transformed from a rigid to a floppy structure, and back. This is a little hard to explain without seeing it, so here’s a video showing off these interesting structures, built out of Knex . All you need to do to transform it from the rigid form:


To the floppy form:


You’ll have to watch the video to see how the conversion works.

These are actually amazingly fun to manipulate, and it’s quite surprising when you discover that just by changing one link you completely change the flexibility of the structure!

It appears that if you add even one additional link to this particular structure, you convert it into one that only has a floppy conformation, although I can’t prove that. Here’s Leo manipulating a slightly larger structure:



A Quantum Mechanical Maze Game


, , , ,

Leo designed a maze game (roughly) based on quantum mechanics and entanglement.

Here’s the board (the player tokens are the dime and quarter):


Each square represents a quantum state, so the maze is a state space.There are six paths out of each state, to some other state (or back to itself). (Well, there are supposed to be six paths out of each state, but Leo was being highly disorganized in drawing the maze, so we ended up with a few less in the latter states, but anyway…)

Both players start out in the start state, entangled together. Rounds are collective, that is, players play together. A round begins by rolling two die: First the count die (the green one, in this case) is rolled, and then the path die (yellow) is rolled the number of times shown by the count die. So, for example, if the count die rolls 3, we would then roll the path die three times. Let’s say that the path results are: 4,2,4. Each player then chooses one of the paths to take from their current state to a new state, trying to reach the end state. BUT, there is an “exclusion” constraint(*) that requires that only one player choose each value. So, in the example above (4,2,4), if one player wants to move on path 4, and the other on path 2, there is no problem. Similarly, if both want to move on path 4, there’s no problem because there are two 4s. However, if both want to move on path 2, you have to roll against one another for priority, and the player with the highest roll gets to choose his or her path first, and the other player is left with whatever paths are left.

Simple, but fun!

We had ideas for a bunch of enhancements, esp. re-entanglement if we ended up on the same state, and I had this fantasy of using <bra|OP|ket> notation to record the paths, but we never got around to these. It would have been  a bit better with a more state space maze.

(*) It occurred to me that it would have made more physical sense for the exclusion constraint to keep the players out of the same state, but that would have required redesigning the board from scratch, with two starts next to one another, or something. We’ll have to think about this for a redesign.


HopScotch Turing Machine


, ,

(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!

You can play it here, if you have HopScotch.

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!)


Playdough Science


, , , , , , , ,

I decided, somewhat insanely, to get Leo a subscription to Science magazine, the lead publication of the AAAS, and one of the two top international scientific periodicals (the other being Nature). My concept here was that we might find at least one interesting science thing to talk about each week, and the pictures in Science are way cool!

(I had gotten him a subscription to Scientific American a while back, but, to be honest, the articles are too long and too wordy, and frankly dumbed-down and pretty boring, so Leo really never got into them. I think what’s going on, in part, is that the graphics/word count is too low in SciAm, whereas in Science it’s way higher, so Science is more like a graphic novel than SciAm.)

The first issue arrived this week, and it turned out that there’s a very high density of articles that were quite interesting, both graphically and in terms of content. Leo was especially interested in this one:


I can hear you yawning, even over the internet!

But wait! I turns out that this is a really cool paper about making very interesting nan0-alloys by combining a bunch of different molecules. It has great graphics, for example:


Notice the interesting seemingly-3-Dimensional egg-like thing in the middle of the picture. The reason that it seems 3D is that is is 3D! We got hold of some PlayDough and made a bunch of model of the various nano-alloys depicted in the paper. Here’s another:


I’m not actually sure which one this was supposed to be…possibly the AuCuCo that it’s sitting on top of.

Anyway, this devolved…or perhaps I should say “evolved” into our creating a complete Clay Science Museum!

Here’s the whole museum:


In the center we have the anatomically correct insides of a person. Here’s a close up:


It’s a male, in case it isn’t obvious; I’ll spare you the details! 🙂

This is a ciliate protozoa that we saw in the microscope the other day from a sample of pond water:


This is the LHC (the rings at the bottom are the smaller injection rings, and the ATLAS is the blue thing at the top):


This is quantum tunneling. (Too hard to explain!)


Here’s the galaxy (supermassive black hole in the center, of course), and the solar system:


Later on Leo stuck his finger in the middle of the black hole to create a singularity.

[Aren’t you relieved that MineCraft isn’t mentioned ANYWHERE in this post! Ummmm … Oops!]



Livestock Crisis Algebra


, ,

Leo’s been reading an Algebra book, and giving me problems from it.

[Teaching principle [1]: Don’t give kids problems; Instead, let them give YOU problems, at least for a long time into a new subject. Pretend to struggle, and show your work in detail. Get things wrong occasionally. This models how to do the problem, correct mistakes, and shows that mistakes are no big deal. And if you make it look fun enough, you being an idiot will keep their attention for hours! Eventually you can expand the game to you asking THEM question!]

One of the problems had to do with farm animals. MineCraft has many funny creatures. Early on Leo’s exploration, he and I would play together in worlds he was creating [2]. In order to be maximally annoying, I would flood his creations with animals — pigs, mostly. Leo dubbed this a “Livestock Crisis”, and would get very upset at me; Success! 🙂

Anyway, this created an excellent opportunity to do some on-the-spot MineCraft Math!

We started with the problem of how many pigs you could fit into a pen of a particular size, like this one (note the curious chicken!):


This isn’t a completely trivial problem because you have to calculate the inner area, not the outer area, and then divide by the area taken up by a pig. Okay, it’s pretty trivial (but not for a 7 year old)!

In the example above, the outer area is 10×14 block, and the walls are 1 block thick. We assumed that a pig is 2×1 blocks. We calculated the area for this problem: (14-(2*1))x(10-2*1)) => 12*8 => 96sqbks (square blocks). So, you should be able to get 96/(2*1) => 48 pigs into that space.

Here’s 48 pigs:


Uh oh. That definitely doesn’t look right! Hmmm.

Before trying to fix it, let’s turn the whole thing into a formula: Let L and W be the length and width of the outer wall of the pen, and T be the wall thickness. And let A (or P for a pig) be the ground area of an animal. Taking our math above:

(14-(2*1))x(10-2*1)) => 12*8 => 96sqbks, and
96/(2*1) => 48

and just replacing the right symbol for each number:

96/P=>96/2=>48 … Voila … well, sort of, but it didn’t work.

So, the only thing that we made a rough estimate of in the above was the ground area of a pig. We guessed 2×1 = 2sqblks. But in reality, a pig is 0.625 blocks wide and 1.25 blocks long, which is only 0.78sqblks!

Okay, so let’s use our formula to make a new estimate. Mostly things are the same:

But the pig (P) is WAY smaller:

So the result is WAY bigger!
96/0.78=123 pigs !!!

(It jut occurred to me that I should be teaching Leo dimensional (i.e., unit) analysis at the same time… Oh well, next time!)

Okay, so 123 pigs … well, here’s about 123 pigs.


We actually lost count a couple of time, so we don’t really know how many pigs are in this pic, but it’s definitely about 123, probably only +- 1 or 2. And yeah, that looks WAY better!

For the record, again not that you can read this, here’s the white board recording our process:


Notice our incorrect analysis of pig size at the top, and the 3D model of the pen at the bottom. (We very quickly realized that the height isn’t relevant, except that pens have to be 2 blocks high to keep the animals from escaping!) At one point I also tried to simplify the polynomial product by multiplying it out by FOIL. I was so pleased with myself demonstrating how to simplify the expression in this way that it was a bit of an embarrassing letdown, not to mention confusing to Leo, when I got to the end and the multiplied-out form was not nearly as nice as the factored form! I guess that trick is really only useful for complex moduli, as in quantum mechanics.

Down the left side is another problem we did once we had the formula, applying it to 3×2 cows in a 100×100 pen with 2 block thick walls. Ready? 644 cows!


[1] I’ve just now raised this to the level of a “principle”, but don’t listen to me; I’m just making this up as I go along; What to I know about teaching!?

[2] One of the great things about MineCraft is that it’s designed for users to play collaboratively in the same world. (In the iOS version of MineCraft this is incredibly simple if you’re on the same LAN; When you create a world, it automatically starts it as a server, and opens a port to it, and anyone else on the same LAN can just connect directly to it. This is quite impressively well implemented!


MineCraft Seeds & Random Math


, , , , , , , , ,

[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!)]

One of the (many) good things about MineCraft is its programmability, which I’ve mentioned before. But there’s even a simpler sense in which it’s sort of programmable, which is that you can set the randomization seed when you create a world. Leo got into this because one of the (many) other good things about MineCraft is that there is a community, even at Leo’s age, of kids (of many ages!) who have explored a huge amount about the world, so he learns from his friends, and also from the web, about many cool words that have been discovered using various seeds. Here’s an example, but there are literally hundreds (maybe thousands!) of these!

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.

Here are the blackboards that I used in the lesson plan, with some (too brief) commentary. I strongly recommend this video for a really well done explanation of the whole conceptual space (except for the quantum computers).

Let’s start with determinism v. non-determinism:


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:




Pooping Diamonds (Pythoncraft!)



In a previous post I described how Leo and I have been using redstone to create digital hardware in Minecraft — or at least to try. This approach to interesting Minecraft is like pulling teeth. (More precisely, it’s like building a computer out of sand…almost literally!)

There are also several ways to program the Minecraft world itself. One way involves command blocks which allow you to execute arbitrary sets of Minecraft commands. We haven’t really tried this yet, but it seems kind of painful. But you can do some pretty complex stuff done this way, like this amazing Turing machine, and this complete SPARC CPU!

A much more direct way to program the Minecraft world is to reach into the server itself through its API. There’s a very good intro to programming in Python, by Craig Richardson, that’s all set in the Minecraft world. Getting the software to actually work requires hacking through the usual morass of stack hassles, wrong program versions, broken paths, missing files, and blah blah blah, but once I got through all that, it actually worked! (I’m always amazed when something in the Unix world actually works, considering the utter mess that is the Unix software stack!)

Once I got this to work as advertised, Leo and I were able to actually program in Python and have it take effect in the Minecraft world!

Considering that this is the first time Leo has programmed in an actual text-based programming language, we started with something simple.

First Leo wanted to build huge buildings, so we wrote a triple-nested loop:

def maketower(x1, x2, y1, y2, z1, z2, blocktype):
  for x in range(x1,x2):
    for y in range(y1,y2):
      for z in range(z1,z2):

It only took about an hour to get him to understood the nested loops.

Next he wanted to drop blocks near us, and I had to idea to make this happen continuously as we move around. Here’s that program (blocktype 57 are diamonds):

def poopie(blocktype=57,sleepsecs=1):
  while True:

If you call this with sleepsecs=0.1 or so, then it leaves a trail as you move …thus its name! 🙂

Here are a couple of view of what the world looked like after we had made a bunch of giant blocks of diamond and emerald using maketower, and we had also flown around for a while pooping diamonds:

The totally great thing about this is that I can use Leo’s natural attraction (one might say “addiction”!) to Minecraft as a way into Computer Science for real. Unfortunately, Python is a ridiculous programming language — sort of the modern version of BASIC, or possibly worse!

At some point I’ll port the interface to a Lisp; then we’ll actually be able to do some real computer science!


Minecraft (Redstone) Computing


, , , ,

Of course, the most interesting thing about Minecraft for us STEM Hacker parents is redstone. Redstone — more precisely redstone dust (but I’ll just say “redstone”) — is basically wiring, and combined with lights and levers and torches, and a few other do-dads, pretty much enables you to build any sort of digital computing device that you can figure out…although you’re almost literally building it from sand! Given the low-level-ness of the whole thing, and some other annoying problems — mainly that redstone (dust) is highly resistive as compared with real wires, and everything is physical, so you’re running highly resistive and self-interacting wires all over the place! — you really have to think like a VLSI engineer rather than like a computer scientist. Yet there are folks who build quite amazing computing machines — like complete huge Turing machines!, and other insanely complex devices (this one’s actually a playable Pong in redstone, and this one’s an utterly insane graphing calculator! — in Minecraft. But I’m guessing that those folks (a) aren’t trying to collaborate on the project with a 7-year-old, and (b) have WAY too much time on their hands.

(There are ways to think in Minecraft like a computer scientist — specifically, you can actually program the world in Python! But I’ll get to that another post.)

Anyway, so Leo and I set out to do something pretty modest, create a binary counter using adders. We had worked through how a redstone adder works based on this very good video. (I highly recommend watching that video to get a very good sense of how redstone works if you don’t already know.) So we designed a counter. The design is to use two adders linked in a ripple carry configuration, and a clock whose tick causes the adders to latch their output and  to pass the latched output back to their inputs, permanently adding 01 on each cycle.

Here are the two adders linked in a ripple carry configuration and with a manually-operated output latch — no clock or fed-back inputs yet:


There’s a lot to see here, and watching the video linked above about adders will help a lot to understand what’s going on here, if you care. But one thing to notice is the latch repeater (on the rightmost side). Notice that the redstone just ahead of the repeater is going dim. This is one of the really annoying things about redstone: the signal is both slow, and fades out after 15 blocks, so you need to add repeaters every once in a while. It’s also undependable in terms of timing, causing all sorts of noise in the signal. As a result, you need to annoyingly put repeaters and latches all over the place, just to get your signals from A to B reliably. But, the above manually-operated ripple-carry adder and latch circuit actually does work.

Okay, so now to the counter. All we should have to do is to add a clock and feed the outputs back into the inputs (and set 01 as a permanent input), right? Well, all that isn’t as easy as it sounds.

First to the clock. We did the clock by creating a railroad of a certain length, so that the car runs continuously, and each time around sends a signal to our counter. Here’s the railroad:


In the below you’ll see this in various configurations (and with various animals sitting the car — turns out that animals like to get into the railcars!) This worked pretty well. The repeater next to the left track picks up the signal when the car passes it and sends it to the latch, which stays on for a few seconds and then cycles off. This is our signal. We can make the clock-tick arbitrarily long by just making the track loop longer. (We had discovered this trick while trying to make a roller coaster.)

Okay, so now we have to get the latched outputs back to the input side of the adders. This wasn’t so easy, and we tried a couple of different configurations before settling on one that was not overly tortuous. Here’s an early one:


This is a little hard to parse visually, but what’s happening is that the return signals are climbing up to a pair of high-wires (literally!) that bridge them back over the adders and to then land them down a bunch of steps to the correct input. (Note that this pic is backwards v. the above pics; here the inputs are on the right. The clock is at the back, slightly hidden.) This required so many staircases and repeaters that it was too hard to debug, so we ended up with this simpler design:


(This one’s in the “normal” orientation that the first pics above were: Inputs on the left, outputs on the right.)

Here the return signal only has to bridge the ripple carries, rather than having to bridge the whole adder, which required a lot less stair-cases, and many fewer repeaters.  Note the pig wandering around on the input, and the sheep that is now riding around in the rail car!

This configuration actually sort of worked, and it’s fun to watch it run. Here’s another view of it at a different phase just so that you can see that the system is actually clocking:


Unfortunately, timing problems with redstone repeaters made it unreliable. It really needs to have another set of latches on the input side. That would be easy to wire up now that we have a reliable clock, but, to be honest, (a) I’m collaborating with a 7-year-old, and (b) NO, I do NOT have too much time on my hands!