# Percentages may not add up to 100%, but not for the reason you suggest

I saw a chart which had the disclaimer, "Percentages may not add up to 100%, as they are rounded to the nearest percent."

The values in the table were 10.4%, 4.0%, 9.4%, 9.3%, 9.2%, 21.2%, 20.0%, and 15.8%.

This is a use of the phrase "nearest percent" I was previously unfamiliar with.

Tags

1. Jamie Akers says:

Rounded to 1 decimal place may make sense on this 1% occasion.

2. Jeff says:

Maybe it's the nearest 1/100th percent value of the nearest full percentage?

3. acq says:

(me: fires Python and types)

>> 0.4+4.0+9.4+9.3+9.2+21.2+20.0+15.8

89.3

Raymond probably just did mental math. :)

4. acq says:

ups I omitted 1 in front of the first number. So the result is 99.3 — that's certainly much harder to detect without actually calculating everything.

5. As Andy H points out:

There are eight numbers which sure look like they were rounded to the nearest 0.1%.

The maximum error in rounding to the nearest 0.1% is 0.05%.

Even if all the rounding happened to be "down", the maximum error you would expect from eight numbers would be 0.05% * 8 = 0.4%.

The rounded numbers add up to 99.3%, which is an error of 0.7%.

6. lib says:

To be charitable/whimsical, one possibility: only the percentages 4.0% and 20.0% have been rounded to the nearest percent, being something like 4.3% and 20.4%. This would make the numbers add up.

7. voo says:

@Maurits Huh? If we round only in one direction we get a maximum error of 0.9999..% = 0.1% per item. And 0.1 * 8 = 0.8 > 0.7 so that works fine. But that'd be a really strange definition for "round to nearest" :)

8. JM says:

The solution is simple enough: round the total to the nearest 100%. This should give you a sufficiently wide margin.

Also, by amending the phrase to the more convenient "percentages may not add up to 100% due to rounding" you have all your bases covered, really. Nobody said which values were being rounded, or when, or how.

Speaking of bases, we're just assuming here the rounding was done in base 10. This seems too limiting.

Finally, we could see the problem as getting a total of 100% from a set of values rounded with different rules as an instance of the knapsack problem, meaning we have just transformed a boring accountancy issue into an interesting exercise in optimization.

If you're not having fun, you're just not being arbitrary enough.

9. AsmGuru62 says:

Instead of such disclaimer the proper code should have been written:

1. Make a variable of 100.0%

2. Calculate percentages for every category of 'whatever' it is needed on the chart

3. Subtract every percentage from the value in step 1.

4. Do not calculate the last category – simply accept the value from step 1.

10. Neil (SM) says:

@Maurits: I assume by "always rounding down" he meant using some kind of floor or trunc function to one decimal place, which would make the result plausible.   Although that explanation itself is not very plausible!

11. Mark Steward says:

Wait, computers rounding down by default is now not plausible?

12. well-actually says:

I believe Raymond's point was that the numbers are not rounded to the nearest percent as claimed, but instead to the nearest tenth (0.1) of a percent.

I've never understood why these notes say "may not add to 100%" rather than "do not …" unless it's charting live data.

14. Mark says:

well-actually: yes, I was replying to all the astonished comments at the (entirely irrelevant) rounding down.

15. Huh? says:

Wait, computers rounding down by default is now not plausible?

No, because every sane format function would round to the nearest value of the requested decimal resolution, not always down. Probably, you will 0.99999999999999999999999999 formatted to 3 digits shown as 1.000, or not?

16. Andy H says:

Even allowing for rounding to 1dp, they still don't add up to 100%

Unless the *always* round down rather than to nearest 1dp

Maybe 4.0 and 20.0 *were* rounded to the nearest full percent, meaning their maximum error is 0.5%, so change your calculations to (0.05 * 6) + (0.5 * 2) = 1.3%, and you're back within the possible error limits.

Of course, then you have to wonder why they rounded 2 numbers correctly and 6 incorrectly…

18. Another possibility – maybe there were a slew of other values which added up to around 0.7%, but which were individually too small to be worth adding to the list.

19. Neil says:

@acq Save yourself a CreateProcess and use SET /A instead.

20. 640k says:

rounding is not truncation

21. Gabe says:

Truncation is just rounding toward zero.

22. Ricardo C says:

We know you can round down or up.

I believe that Raymond's point is:

"This is a use of the phrase "nearest percent" I was previously unfamiliar with. "

The use of the phrase is ambiguous and provides no helpful information.

23. set /a doesn't seem to handle floating-point numbers on my system.

24. Cesar says:

@Neil: that assumes he already has a cmd.exe open (I am guessing this "SET /A" you speak of is from cmd.exe). Maybe he fired python directly without opening cmd.exe first. Maybe he, like me, is using another operating system and *does not* have cmd.exe at all (nor CreateProcess, for that matter, unless you count Wine).