Saw a neat tweet from Gary Rubinstein yesterday:
This morning I thought it would be fun to look at the “Russian Peasant” multiplication video with the boys. Here’s Rubenstein’s video:
I had the boys watch the video twice and then we talked through an example. My older son went first. He had a fun description of the process: “It is like multiplying, but you aren’t actually multiplying the numbers.”
Next my older son worked through a problem. This problem was the same as the first one but the numbers were reversed. It isn’t at all obvious that the “Russian Peasant” process is commutative when you see it for the first time, so I thought it would be nice to check one example:
Next we moved to discussing why the process produces the correct answer. My older son had a nice idea -> let’s see what happens with powers of 2.
The last video looking at multiplication with a power of 2 gave the kids a glimpse of why the algorithm worked. In this video they looked at an example not involving powers of 2 (24 x 9) and figured out the main idea of the “Russian Peasant” multiplication process:
This was a really great project with the boys. It’ll be fun to work through Rubinstein’s videos over the next few months. I’m grateful that he’s shared the entire collection of ideas.
Mike's Math Page 
This has an actual usage in CPU/ALU, where multiplication of 2 and division by 2 mean bitshifting registers, which are easy to implement in hardware; so is testing a bit. Adding values is easy to implement in hardware too, it’s another basic building block, of course.
When you handle the two operands this way and add the current state to an accumulator register in case the 0th bit is 1 (one operand becoming odd) you finally get the multiplication result. Rounding down, in this case, is simply dropping a bit shifted out of a register.
Se it this way: 9 x 10 = 1001 x 1010
>>>>>>> x <<<<<<< add to accumulator: 00001010
00000100 x 00010100
00000010 x 00101000
00000001 x 01010000 -> add to accumulator: 01011010 = 90
To minimize steps the first operand choosen will always be the smaller one, needing least steps to get down to 1.
Something went wrong in posting, one line removed from the calculation. Can you figure it out?
Also take a look at Napier’s “location arithmetic” https://en.wikipedia.org/wiki/Location_arithmetic