(An archive question of the week)
Last time I looked at reasons for learning to estimate. In searching for answers on that topic, I ran across a question that touches not just on reasons for estimation, but on other ways to check an answer, and on some of the specific ideas we will be looking at later.
Checking addition by rounding
The question comes from Stephanie, in 2002:
Checking When Rounding This is what I do understand: To check Decimal ADDITION: 13.3 + 26.5 = 39.8 To check: Look at the tens, and round: 13. + 27. = 40. Then look at the addition answer and round it: 39.8 is rounded to 40. Answer is correct What I DON'T understand: To check Decimal SUBTRACTION: 7.6 - 1.4 = 6.2 OR 86.8 - 43.9 = 42.9 To round and then check, I don't understand what I need to round, and do I add to check?
We love it when students tell us what they do understand, and then clearly show what they don’t! That makes it much easier for us to see how we can help.
Stephanie has learned to check an addition by rounding each addend to the same place (to the nearest integer, here — she probably meant “look at the tenths” as part of that process), using the standard method of rounding to the nearest. The result she gets is just what she gets by rounding the claimed answer, she concludes that it is correct. I’ll have some comments on that, but on the whole it is well done.
For subtraction, the basic concept is the same, so we will have to find out what it is that is stopping her from doing it. But the last question, “Do I add to check?” suggests that her issue is that she has learned to check subtraction by adding, and she is wondering if that is what “check” means here.
I first looked at the addition, pointing out that she made too strong a conclusion:
It's worth noting that this check does not tell you that the answer is correct; you just know that it makes sense - it is not too far off. But if the correct answer were 39.9, you would not know. Also, the answer you get by rounding and adding will not always be the same as what you get by adding and then rounding. For example, 12.5 + 23.6 = 36.1; but 13 + 24 = 37, and 36.1 does not round to 37. What has happened is that the errors introduced by rounding accumulated when they were added together, so that the result is more than .5 away from the exact answer. But since 36.1 and 37 are reasonably close, the answer is reasonable.
This is an example of “rounding error”: the result after rounding the addends is not always the same as the result of rounding the sum, so we shouldn’t expect that to happen always. Stephanie’s example is atypical, and gives too optimistic an expectation. Knowing what to expect allows you to decide whether the error you do get is small enough to trust the answer.
So on one hand, you shouldn’t call an answer wrong when the estimate is a little off; but on the other hand, you can’t be sure the answer is right just because the estimate looks good!
Checking subtraction by rounding
Next, I looked at the issue of subtraction:
To check subtraction by rounding, do the same thing: round and subtract, and see if the answer is close to the answer you got. The way the rounding test works is simply that you replace a detailed operation (adding decimal numbers) with the same operation on simpler numbers. So for the second problem, you would subtract 87 - 44 and compare that with 42.9.
I’ll be examining the first example later; it raises an issue I didn’t want to cover at this point. This second example works as neatly as her addition: We round 86.8 – 43.9 to 87 – 44 = 43, which is very close to 42.9, so it is likely to be correct (or at least is not clearly wrong).
I didn’t yet comment on other ways to check subtraction, but left that for her to bring up if she wanted to.
Other tools for your toolkit
Her reply dealt with two other issues: first, why we would bother rounding; and, second, as we’ll see below, what’s going on in her first example. Here is the first part of her answer:
I understand your directions, and thank you. But I want to know if this is one of those weird Math things that isn't really needed? What's the use of checking, if you are only going to get a ballpark answer? That seems like a waste of time.
First, I dealt with different ways to check a subtraction, and why they are all useful:
Checking is important, but each kind of check has a different value. Checking by estimation is especially important when you use a calculator, since you know it won't make mistakes on the details but if you fail to type in a decimal point or a digit, it can make big errors. So if you did a calculation that said you needed, say, 1.5 tons of concrete to make a bridge strong enough, and your estimate said it should be about 150, you would go back and do the calculation again! Another kind of check, "casting out nines," is unaffected by the size of the answer, but would show if some one digit somewhere was wrong. And that check, in turn, is unaffected by the common error of transposing two digits, so you might prefer another check that would reveal that error.
So we have several tools in our checking toolkit, and each will catch a different kind of error. (In the same way, doctors have different ways to prevent infection, from washing their hands to a variety of antibiotics, and they may use all of them rather than depend on one.) If you are not familiar with “casting out nines”, you can search for that term on our site or elsewhere, to see both the method and its limitations. Here is one place to read about the latter, with a link to an explanation:
When Casting Out Nines Fails
I didn’t mention a third method, which Stephanie had mentioned in her initial question: You can just add in reverse. In her first example, we have
7.6 6.2 - 1.4 + 1.4 ----- is equivalent to ----- 6.2 7.6
Since the addition is correct, the subtraction is too. And this is a very convenient check, because we can literally add upwards, just reading from the bottom as if it looked like this (but without actually rewriting anything):
7.6 ^ ----- | + 1.4 | 6.2 |
This check will catch any error, as long as you do it correctly. But the other checking methods will catch errors you make going both ways.
Checking by rounding in harder cases
But she had another question, wondering if something was wrong with rounding for her first example. This is probably the very reason I had left that example until now.
Also, can you please show me how to check the first problem I gave you when I asked about subtraction? I am wondering if my book has explained this wrong. This is what it says: "To round a decimal number to the nearest whole number, look at the tenths digit. If the digit is 0-4, the ones digit remains the same and all the digits to the right are dropped. If the tenths digit is 5-9, the ones digit is raised one and all the digits to the right are dropped. This is called a CONVENTION."
Clearly, Stephanie tried rounding and something went wrong, and she thinks the rounding method she is using may be incorrect. The book emphasizes that the rule they teach is not the only way to do it, but is a “convention” — that is, a definition that has been agreed upon, rather than being mathematically necessary. This is so because when a number ends in 5 in the tenths place, there is no one whole number that is “nearest”, and we have to make a choice. But this convention, and even the very choice to round to the nearest whole number, is not always the best, as we’ll see.
So I demonstrated how to check by rounding with her first subtraction example:
Let's look at
7.6 - 1.4 = 6.2
To estimate the answer, you can round 7.6 up to 8 (since 6 >= 5 ), and round 1.4 down to 1 (since 4 < 5 ); 8-1 = 7. That doesn't mean there's an error, because rounding can introduce an error this large. If the estimate were, say, 70, you would know something was wrong.
Here I just did what she has been taught (following the convention she quoted), rounding to the nearest whole number. As I mentioned earlier, when you check by rounding, you have to develop a sense of how big an error to expect, in order to make an appropriate judgment of the result. This is probably Stephanie’s main difficulty.
But, as discussed previously when we talked about rounding, this can be improved by not following the convention:
One way to improve the estimate when you do this is to think about how subtraction works. We added something to 7.6, and subtracted something from 1.4; both changes will have increased the answer. (Do you see why?) So we know the real answer is LESS than 7. That makes our check valid. Also, since I know about this problem, I prefer to round both numbers in the SAME DIRECTION when I subtract (and in opposite directions when I add). Here, the .6 wants to go up and the .4 wants to go down, and neither is more persuasive than the other (both are .4 away from the nearest whole number). So I would arbitrarily choose, say, to round both numbers up:
7.6 - 1.4 ~ 8 - 2 = 6
That gives a more accurate estimate. But even this way, it won't necessarily be exact.
Here I have shown two ways to improve the check: either think of it as an inequality, telling us that the correct answer is less than 7, which is true of 6.2 so that it is valid; or modify the way we round in order to minimize the error. (Note that if I rounded both numbers down, I would get exactly the same result, so I didn’t spend much time deciding which way to go! This is another thing you learn with experience.)
In conclusion:
You can find several discussions of rounding in our site (try the FAQ first); you'll see more about different conventions for rounding when you are exactly between two numbers. But the important thing here is to realize that rounding is only a tool, and considerations apart from the rule for rounding a single number can lead us to depart from that rule when the goal is to estimate the result of a calculation involving several numbers. The interactions among numbers can make a big difference.