How to respond to the two-handed approach to swapping

Question

I was introducing lists to someone young (in Scratch). Creating a list is boring, so I opted to introduce something that you can do with lists, but requires some thinking: swapping. I introduced it by putting out four pencils in a row, like this. I asked them to swap the second and fourth items in the array (in reality).

| | | |

They took both their hands, picked up the second and fourth pencils (each in one hand), and swapped them! That works in reality... but isn't right in computer science. So, I told them, try doing it with only one hand. Predictably, they couldn't. I introduced a temporary spot, where they could put one pencil. I was hoping they would do something like this:

Second Item -> Temp spot
Fourth Item -> Second spot
Temp spot -> Fourth spot

They figured it out. But they asked me something like this: "Why can't I use two hands?". I wasn't sure how to answer that. The obvious answer is... the computer only has one hand (this was Scratch, so multithreading didn't exist). But... I'm hesitant to say that for two reasons: (1) in Python, the "two-hands" approach works (a, b = b, a, see this Stack Overflow question) and (2) multithreading exists, and there are some (obscure) ways to swap two variables without a temporary variable. So, how should I answer the question "why can't I use two hands"?

Remember, they are just learning lists, so explaining something like multithreading would be too difficult.

What's a good way to answer that question, without confusing them?

Answer 1

Don't overcomplicate things. Your first instinct, that the computer only has one hand, was the correct one.

This is a regular problem that new teachers have, and it sometimes takes a few years of frustration to burn out the idea that everything you say must be formally true. If we say something that is untrue, the reasoning goes, the students will remember it and use that wrong idea to badly misunderstand things later.

Let me give you a slightly different mental model of learning, and you'll find all of the support you need in the absolutely fantastic book "How People Learn II", which is a big volume that describes everything we really know from research about how learning actually works in the brain.

We (1) build mental models by (2) connecting new information (3) to things that we already know. Furthermore, (4) abstraction is the brain-process of finding the similarity in (5) similar mental models. (6) In order to build upon prior knowledge, (7) it must already be fairly well understood. If it's not, and you simply don't have the prerequisite knowledge, you are unlikely to build any mental model at all.

(That should make some sense; if it's not already fairly concrete within your mind, it's too nebulous to glom new ideas onto.)

So, with that as a model of learning, there are a few implications:

1. We need to help students build small, clear mental models. They can then use these in the future to build further, richer models. This lends itself very nicely to the KISS principle. Don't try to introduce too many variations to the idea at once. Leave the complicating for the next step, or you won't obtain any model at all.
2. Before there is already a fairly clear mental model, learning isn't really taking place, so little of what is said will be directly remembered. Corollary to this is that the danger of them being confused by some overly literal interpretation of what you said while explaining how to swap in Scratch once they encounter threading later down the line is completely negligible. They won't remember much of the explanation until they can build a mental model, so they won't remember those kinds of details. In addition, there are simply too many cognitive models that have to be built between swap in Scratch and multithreading for one to hamper the other.

Don't let perfect be the enemy of progress. Keep it simple and focused on the small concept they are learning right now, and be comfortable that that will support them best as they grow and develop and complexify ideas later.

Answer 2

Re-evaluate what you think is "right", because you aren't

but isn't right in computer science

This is simply incorrect. Your student can create two variables called LeftHand and RightHand. Copy value "red" from position 1 to LeftHand, copy value "green" from position 4 to RightHand, copy values back to positions 4 and 1 respectively. Job done.

Is this optimal? No - but you didn't ask for optimal, you asked for a solution which works. Your student gave you a working solution, and you've rejected it because of your own preconceptions of how many variables they "should" use, or how many steps it "should" take. Neither of those preconceptions are correct. There's no time or RAM pressures here, so the student is perfectly free to do it their way. (Edit following your comments elsewhere: Nor do they have to consider concurrency where someone else could move the pencils in between.)

And not only are they free to do it this way - if they find it easier to understand then they should. My background is in safety-related software. Coding standards in safety-related software prioritise readability, maintainability and ease of understanding by other coders, ahead of pure speed, because the most intractable bugs almost always come from people trying to be too clever. If you keep the concepts simple, you don't make mistakes and your code is more likely to work first time.

In short, you are committing a cardinal mistake in software engineering, which is premature optimisation (which as every software engineer should know is the root of all evil). Your student is not making that mistake, and that currently makes them a better software engineer than you!

Certainly after they've got a two-handed solution, you can have them do a one-handed version with a single slot. You can then show them that it takes fewer steps and one less variable. The answer to "why can't we...?" is simply "you can if you want, but look, it's more work". Most people would rather do less work, so it's a win all round.

Answer 3

Your problem is that you tried to let your student "program" without establishing a language. Thus they were free to write their own "language" in which you can do two things at once because you have two hands. If you'd asked them to rotate 3 objects, they would have picked up the third pencil in their mouth or so.

You could have asked them "suppose you're a crane driver" then, because they obviously have only one crane, they would have solved the problem "correctly".

May this also be a lesson to you to think very hard about everything you ask your students. Don't improvise. Or just learn for next time.

Answer 4

They took both their hands, picked up the second and fourth pencils (each in one hand), and swapped them! That works in reality... but isn't right in computer science.

It depends on your paradigm. You are teaching the swap algorithm you know, but haven't explained to the students (or at least in the question) what things are. Here is a perfectly valid way to look at the operation, using two temp variables, 'Left Hand' and 'Right Hand':

Second Item -> Left Hand
Fourth Item -> Right Hand
Left Hand -> Fourth spot
Right Hand -> Second spot

In fact many students will do it this way (with two temp variables) when they attempt to do swapping for the first time, I'm pretty sure I did. Some languages have swap operations built-in so you don't require a temporary variable.

In this particular case I think it would make more sense to say that you can only move one pencil at a time rather than you have only one hand. After all I could pick up the pencil in spot two and place it in slot four while picking up the pencil there at the same time with one hand.

The analogy breaks down in other ways, for instance normally you make a copy of the item in the temp variable and it exists in two places until you overwrite it in the array. I think using things like colored blocks here and making copies into variables would be a better way to visualize what is actually happening too...

Answer 5

This question reminds me of when a student failed to understand why a third variable was needed to exchange the value of two variables (i.e. to swap A and B, C=A, A=B, B=C). I managed to illustrate this to them by placing an item (mobile phone) in each of their hands, and asking them to swap the items between the hands. On attempting to do this, they immediately realised they needed a third location (the table) to achieve this.

You may find your list-swapping activity works better if you place the pencils in students' hands. This will help reinforce the idea that each pencil needs a location (hand) to be stored in at all times. You'll obviously need more than one student to make a list that's larger than two pencils, and pandemic-related distancing may be an obstacle.

I'd suggest trying this activity with two or three students sat in a row, and using an odd number of pencils. This will ensure that there is only one hand available for moving pencils about at any time, without appearing to be an arbitrary rule that you've introduced.

Answer 6

In thinking about this, and especially the answer of Graham, I think that what we really do in the standard three step process is a two handed swap without thinking of it. So, it is a failure of the metaphor, actually. So, here is a reframing of the standard process:

Pick up one stick with the left hand (i.e. temp is associated with the left hand). THEN, move the other stick with the right hand (the assignment). THEN put the stick in the left hand into the proper slot.

Or:

Second Item -> Left Hand Fourth Item -> Second spot // using Right Hand Left Hand -> Fourth spot

All you need to explain is that (with a single processor) only one thing can be done at a time and so the swap-with-two-hands has to be sequenced in some way rather than happening simultaneously.

This is to avoid issues in the more general case where you want to swap(m,n) where m and n could be the same. Both hands can't pick up the same stick simultaneously if it has to be sequenced. The bright kids will want to complain that you can't pick up a stick from an empty slot, but the small variation isn't too hard to explain if you think of it beforehand. The really astute ones will notice that assignment is copying, so "picking up one stick" in the program doesn't really leave that slot empty, as it does with physical objects.

(ASIDE: there is a way to avoid that physical/virtual disconnect by using a reference (rather than copy) metaphor of variables, but it is likely not where you want to go with youngsters unless you do it ubiquitously. In essence, a variable is a reference to a value not a box that "holds" the value.)

It also avoids discussions of race conditions with multiple processors.

Answer 7

I do the swap example pretending to have two largish (2-hands-to-lift) boxes side-by-side on a desk (with only enough room for two boxes). After we lift the first we have to look for a place to put it, which feels like creating the temp variable.

But I don't think swap is an especially good example with lists. It's easier to explain swapping just any two variables, x and y. Lists are about using indexes. In Scratch we don't get as much fun with loops, but can do 2 step find-the-index-first stuff like "turn the first 9 into a 6" or "put 12's before and after the first 3".

As far as "computer rules" I like a lighter touch. Swap is one of many clever tricks which happen to work, for now. Motivate the problem with how switching x and y starting with "set x to y" permanently erases x. Then explain how that 3-step dance is actually the standard swap trick. We could have had a built-in swap command but everyone was all "no, everyone knows the trick and it's just one extra step".

Esp. in Scratch you're hoping they like it and move onto a real language. At that point you're going to explain how "Scratch rules" like pre-making variables aren't computer rules at all. But we learned lots of concepts which mostly transfer over with minor changes. In the end: switching values of two variables is a thing; everyone calls it a swap; and it's good to know the trick just-in-case there's no built-in way.

Answer 8

Analogies & metaphors are imperfect, so let's share the expectation that they are just illustrative.

Rules of what is possible (and not) are very important, and we can compare the rules of pencils moved with hands and what computers can do — but we need to define both, in part so the rules for the metaphor can be compared with the those of a computer.

These rules can be reasonably terse and simple to state.

The computer can copy a value from one storage location to another storage location.  (Computers generally copy data rather than moving it.)

Your hand can simulate action of making a copy, and whether the hand itself represent another storage location that can be utilized while doing something else is a matter of definition and explanation of rules.

Since we're talking about information rather than physical items, I might prefer a metaphor of a spreadsheet: swapping two cells in a spreadsheet generally requires another free cell; a pencil and piece of paper with some boxes holding symbols might also work, you need to stipulate whether human memory is outside of the metaphor (i.e. not be used for storage).

Programming languages support constructs & expressions that require additional implicit storage, and language implementations introduced temporaries for these purposes: Python's a,b=b,a is such a construct, while any language's general purpose expressions is another: you can't really compute a*b+c*d without holding the result of one of the multiplications somewhere (on paper, in your head, in storage...), while doing the other.

Answer 9

Ben's answer is great, but allow me to suggest that you don't need to "respond" to the two-handed approach at all: just say when you're explaining the problem in the first place that they can only use one hand and they can only hold one item at a time.

Students are less likely to need a justification this way, because you haven't changed the rules to forbid a solution after they've come up with it themselves. If a justification is required, the question is not "why can't I use two hands?", but rather "why is it useful to know how to do this with one hand?". And the answer to that is that the solution using one hand can be translated directly into code, whereas the solution with two hands can't be.

Answer 10

Graham pointed out that the assumtions of the question are wrong. And Peter Cordes elaborated a bit in the comments.

Considering a target VLIW (Very Long Instruction Word) architecture can help sharpen this argument further.

The basic idea of VLIW is that a Very Long Instruction "horizontally" packs a number of instructions per single VL-instruction, all of which are executed in parallel in one machine cycle. The requirement is that the multiple instructions in a VL-instruction need to access disjoint memory/registers.

In terms of more popular architectures, VLIW is:

• Like pipelined superscalar architectures except that the compiler rather than the hardware does parallelization scheduling
• Like RISC in that the complexity is shifted to the compiler

So

x = 1
y = 2

can be packed as one VL-instruction

 x = 1 // y = 2

Whereas

x = 1
y = x + 1

can't because x overlaps.

(Using the notation that multiple VL instructions are on multiple lines and "subinstructions" packed into a VL instruction are on one line "//" separated).

With that background we can write swap as

lh = x // rh = y
x = rh // y = lh

Whereas your preferred solution

t = x 
x = y
y = t

is interlocked at each stage and so is hopelessly sequential.

tl;dr

The VLIW oriented swap is 33% faster — 2 vs 3 — than the standard imperative one. When it is naively sequentialized it's 25% slower — 4 vs 3.

Note

The two-hand analogy is right in being more efficient than with one hand. However it's not so right in this that it seems to be able to do it in one single 2-handed swoop. Whereas (for VLIW at least) it's two 2-handed swoops. Our hands have enough muscle intelligence to criss-cross without colliding whereas data-buses dynamically hop-skipping over each other is.. uh... still futuristic sci-fi😂.
IOW analogies/metaphors may help but don't go all the way.