Age groups used: Year 10s (~15 years)

I’ve been using the most excellent CS Unplugged activities for some of my classes this year – they are predominantly targeted to primary school classes, but they adapt very well to my high school students (either we roll through the activities faster or at a higher level).

It is now nearly two decades since the CS Unplugged activities were published and I think it’s important to note that they are still generally extremely relevant and useful to modern curriculum. Technology is used, implemented and reimagined all the time – but the underlying principles (generally) remain the same.

As a relatively fresh high school teacher, learning how best to position, prime and implement these activities has been a challenge this year – I’d like to reflect and report on how some of these have played out.

Parity – I Can’t Even

Go ahead and take a look at the parity activity presented in CSU.

The article and preamble itself is probably a better introductory source of info than this post, so I’ll skip the explanation and just make a note that your students should probably be pretty comfortable with the concept of binary numbers and why we use them.

Since my students had covered this topic and were comfortable with the idea of binary as “switches” – on/off, yes/no, true/false, it wasn’t a huge leap for them to understand a representation of binary as flipped (switched) classes.

I don’t have much primary school material (the cool stuff). What I do have is a half dozen decks of these cards.

Word of warning about these cards: The 5s are an implementation of Brainf*ck. Which is cool, but not when you have students reading it. So when you get ’em, use white out or a permanent marker or just remove the 5s. Students will also try to scratch off the white out, so be prepared for that :-/

Any deck of cards will be good for these, but it works best if the backs are immediately distinct from the fronts – in the case of Code:Deck, the backs are predominantly black and the fronts are predominantly white, which works well to represent 1s and 0s respectively.

Using Playing Cards: Pros

1. Easy to come by, store, pack up etc
2. Fits the concept of a “magic trick” well
3. Quick to lay out on desks/floor
4. Cards are plentiful, so you can lay out several sets at a time for several groups.
5. If you have lots of small magnets (I didn’t), you can still stick the cards to a whiteboard

Using Playing Cards: Cons

1. Big class? Just pop your demo up on the board using magnets. Cards can be trickier (needs magnets or multiple demos)
2. Squares or circles are easier to flip without giving away the erroneous bit. Playing cards are rectangular.
3. Further to (2) above – the shape formed by the cards is also rectangular, which makes forming an NxN grid feel “off”. Maybe that’s just me?
4. Playing cards are not as immediately obvious as 1s or 0s as there is usually detail on each side which distracts from the “meaning”. Items with solid colour/white provide a clearer distinction.

Reflection

All up – using these playing cards was successful.

I presented the “trick” to the students pretty much as described in the activity: I had them lay out five rows of five cards and then to make things “harder”, added an extra row and column. At this point, a few cottoned on to the fact that this was clearly not making things harder, but an essential part of the trick. Nobody was really sure why I was doing it though.

Data grid – no parity bits

Data grid with parity bits at top and right

Now we can use parity to identify the error (checking) and flip it back (correction)

This particular class was ~15 students (yes, I’ve been lucky with class sizes this year), so I set up two desks with a grid of cards on each and around half the class observing either side. I then proceeded to “bounce” between the two grids, identifying the “flipped” card on one side of the room, while the other side picked another card to flip.

My year 10s, who up until now had been pretty jaded about the whole affair, suddenly became interested.

A few theories were floated as to how this was working, though nobody managed to figure out the “secret”. They ascertained that flipping multiple cards broke the trick.

We stopped and discussed the methodology behind parity (and the trick). I then had them split into 2s to try it on their own. (some did this well, some were “too cool” to try. Ho-hum.)

Extension – Binary Representation of Data as Bits

My students have covered the concept of binary number systems before, and they understand (I hope!) the idea that binary is used by computers because (among other reasons), it’s very easy to show numbers using switches – on/off or electrical current/no current (I didn’t use the CSU intro to binary – it’s pitched a little young for my 10s and I was confident they’d understand the more straight mathsy counting/conversion method).

The last half of the lesson involved discussing the use of binary digits (bits) to represent all the data that is transferred through our networks and to our storage. It’s very important that we have a way of knowing that the bits we receive are the same as the ones that were sent. Parity is a simple and cheap way to do this – but it has limitations.

The students went off to research and experiment on what kinds of limitations are encountered when using parity for error checking/correction. We came up with definitions to distinguish between checking and correction and how corrupted your data can become before you can’t do either one (how many bits can be changed at once? does it matter which bits?). The students came up with some “rules” (such as, “If you have n rows and columns, you can flip n / 2 bits before checking fails” or “Bits can be flipped but have to be in different columns and rows”), which we tested as a class or in pairs. Most rules failed – which is good! – but this is a great opportunity for discovery learning.

Further extension for the quicker students let them look into checksums, how they work and even manually implementing a checksum.

For the whole class – this activity leads really neatly into the Peruvian Coinflip (which can be a little overwhelming at first glance, but once you try it on your own is pretty straightforward) as this introduces the idea of using a hash to verify input.

Concepts: Binary representation of data, error correction and checking, metadata – parity adds nothing to the original message itself, transmission errors/failure.