[cafard]

Back in the days before computerized cash registers, this was typically how cashiers made change. Hand one $5 for a $1.34 purchase, and the cashier counts it back out as

(penny) $1.35 (nickel) $1.50 (quarters) $1.75, $2 (dollar bills) $3, $4, $5

Some still do it that way.

In Teacher in America, chapter "Let x Equal ...", Jacques Barzun mentioned as an example of widespread innumeracy the half-trained cashiers who did not know this technique. That was written in the early 1940s.

[wahern]

It's actually a very useful method for quickly finding the difference between two numbers. And I would think that any computer programmer would appreciate the algorithm. The algorithm is a classic divide-and-conquer technique that is perfect for quickly performing arithmetic in ones head. And it would also be a good entre into teaching things like associativity and commutativity.

I use something similar to avoid getting too much change at a cashier, and to use up loose change (pennies, nickels, etc), except I usually count down and add in the difference. So, for example, if some bubble gum cost $1.28, I might give the cashier $2.03. Then, assuming the bewildered cashier doesn't try to give me the pennies back, I get three quarters for laundry, instead of two quarters, two dimes, and two pennies.

If I don't need laundry change, I'll count up or down searching for the amount that will maximally reduce the number of coins in my pocket (without avoiding bills, which would just be annoying to everybody). With practice you can do this in a split second, and it really blows the mind of some cashiers.

Isaac Asimov said something to the effect that smart people will tend to figure out these algorithms on their own. So it's kind of ironic that now somebody is complaining that it's being taught to kids. I suppose the only real legitimate criticism here is that, according to the link, there's only one example of this method, and then it's never mentioned again. If anything, it should be expounded upon.

[deciplex]

It's a good method for making change, but for doing subtraction in general it is (in my opinion) not so great, the reason being that you have to keep track of more figures in your short term memory, when compared to left-to-right.

To do subtraction by counting up you need to remember: the minuend, how far you've already counted up, and the number you've already counted up to. So, three figures. Subtraction left-to-right (or right-to-left) only requires you remember two numbers: what remains of the minuend, and what remains of the subtrahend. It's pretty easy even for primary school kids once they practice a bit.

Of course, when you're making change, you don't actually care how far you've counted up, because you're not really after the difference exactly, you're only trying to arrive at the correct number of coins and bills. So you can forget that part, or rather you can leave it to the coins in your hand to remember for you, and now you're back to two numbers. But I'd bet that if I asked you to tell me on the spot what the difference was without looking at the change in your hand you'd struggle to tell me.

Making change by subtraction left-to-right is cumbersome because, while you still only need to remember two numbers, after you calculate the difference in your head you must now count out the change, whereas with counting up you're already done.

Different tools for different purposes. I agree with Asimov.

[wahern]

In practice you're not doing every step consciously.

Take, for example, subtracting 188 from 500. Count up to 200 to get 12. The difference between 500 and 200, however, is automatic. It takes no thought at all. So you arrive at 312.

Sometimes you can count down, too. Take 512 - 333. That's just 200 - 21. You can find 21 by doing it left-to-right if you want (it's how I just did it).

I'm not saying it's some kind of magical way to handle arithmetic, and it's not something you use to the exclusion of other techniques. Rather, what you're doing is converting the problem to something that is easier to solve. Left-to-right is a very useful, general, and systematic approach to do that, but there are faster ways depending on context. You can analogize it to programming in that you can trade CPU (left-to-right) for memory (cached tables of differences) to arrive at an optimal algorithm for the problem at hand.

So I would just re-iterate that learning these techniques isn't simply for the sake of doing arithmetic faster in your head. Rather, understanding how and why they work, and how to select the methods, improves numeracy in general.

And FWIW, I never look at the change in my hand. I don't literally count up like a cashier might when handing you change. To be honest, until _just_ right now I never really fully comprehended exactly what they were doing. I knew it was similar, but it only now just clicked that they were counting up in a fashion similar to what I've always just done in my mind's eye by breaking up and rounding numbers. (Not that I think I'm particularly good at this--please don't walk up to me on the street and drill me ;)

[mturmon]

This is a nice observation.

I remember being given change-making assignments in school, and being unable to complete them because I was not sure that the greedy algorithm (http://en.wikipedia.org/wiki/Change-making_problem#Greedy_me...) would always give the optimal result.

I was not able to articulate the reason for my uneasiness until years after I had failed to complete the work.