Mac Calculator is bad at math (update)

by Volker Weber

Adding 19% to 8511.22 renders different results depending on whether you use the % button or multiply by 1.19. The difference is more than 0.04. Which is enough to make you look stupid when writing an invoice.

Update: I have smart readers! Ben has nailed the problem. Calculator is truncating 8511.22 to 8511 before calculating the percentage. Other readers are reporting that they are not seeing this error. Current assumption: This only happens on Intel Macs.

Update: This is only getting better. See this video and find out that the bug is related to the locale in use:

Update: The bug is fixed in Leopard:



That won't bother any Mac user, as long as it looks cool ;-)

Marcus Humann, 2007-02-08

Good to have a windows box. There's no %-button in calc.exe ;-)

Ralf Stellmacher, 2007-02-08

Ralf, there is one, but only in standard view

Marcus Humann, 2007-02-08

Well, I get the same results.

Thomas Bohn, 2007-02-08

The Microsoftie calculator also has no sqaure root key.

Bruce Elgort, 2007-02-08

Does it apply to the PPC, too? As far as I remember, Vowe is using an (intel driven) MacBook.
Maybe the Core Du chip "extends" the FDIV bug from one of its predecessors?

Martin Kautz, 2007-02-08

Dear admin, could you please edit my previous post to nail down the typos/horrible english.

Martin Kautz, 2007-02-08

You should never write vowe with a capital v. :-)

Volker Weber, 2007-02-08

Interesting. So it gave 19% of 8511 instead of 8511.22, which seems to imply either an integer truncation instead of a rounding error as I first assumed. Out of interest's sake, what does it give for 19% of 8511.99? It should give either 1617,09 (as in the video) or 1617.28 (if it rounds before doing the percentage).

Ben Langhinrichs, 2007-02-08

Ah, good old Intel... Works fine and consistently on PPC

Nick Daisley, 2007-02-08

Ben, you nailed the problem. It gives you 1617.09.

Volker Weber, 2007-02-08

Well, that sure must be a side-effect of the Core Duo's inferior floating point capabilities;-)

Martin Switaiski, 2007-02-08

Google would've worked fine if you would have done 8511.22 * 1.19 or
8511.22 * 19% + 8511.22

Gerald Shappell, 2007-02-08

Can somebody try this on Excel on the Intel Mac?

Bruce Elgort, 2007-02-08

I have. This is not a CPU bug. Only Calculator is affected.

Volker Weber, 2007-02-08

Volker, you're sure you got no Pentium under the hood? ;-)

Philipp Sury, 2007-02-08

Freaky! I copied your exact same steps on my machine (Core 2 Duo) and got the same result both times—the correct / expected one, no rounding. How strange.

Ben Poole, 2007-02-08


Was Parallels running Windoze? ;-)

Bruce Elgort, 2007-02-08

Good bug find. Have you reported it to Apple. Oh and how are you capturing the video off your screen? I hope its not via a webcam :)

Andy Mell, 2007-02-09

Maybe the calculator has a problem with the comma as decimal delimiter.

As for the screen captures, Snapz Pro is an excellent choice IMHO.

Ole Saalmann, 2007-02-09

You've got heised:

Martin Schulze, 2007-02-09

You've got heised.

Martin Schulze, 2007-02-09

You've got heised.

Because it's Friday! :-)

Martin Kautz, 2007-02-09

Schau mal auf den Autor der Meldung. :-) Den Link hat allerdings jk eingebaut.

Volker Weber, 2007-02-09

Well the Mac Calculator is really strange...
I'm running a good old PowerBook 12" 866 w/ Mac OS X 10.4.8 and all other imaginable patches installed with the Swiss German layout ("Schwitzerdütsch" anyone?).
Some weeks back, I just discovered that the basic sum calculations I made with my invoices were all way too high!
Reason: Calculator with Swiss German layout ignores the dot [.] key and requires the coma [,] key for decimals!
Problem is that I'm used to use the numpad (I use an external keyboard and screen on my laptop) where only the dot key is available. Thus all my calculation results where way too high.
Funny fact is that when you use the calculator in the Dashboard, then everything works fine.

I already reported this problem to Apple, it's still in "open" state...
Last time I reported them something, it took them months (UI bug on the login screen, present in all Panther installations until 10.3.5 or so) to resolve it and additionally I wasn't even credited. (not that I mind, but still...)

Marc Staub, 2007-02-09

Funktioniert auch in den NL, auch hier rechnet der Mac flsach...

Michael Janßen, 2007-02-09

Neugierige Frage an Volker: Wie sehr wirkt sich eigentlich die Heise-Meldung auf die Zugriffsstatistik aus?

Urban Hillebrand, 2007-02-09

Macht eine kleine Delle in der ersten Stunde. Über den Tag gerechnet sind es etwa 5% mehr Zugriffe.

Volker Weber, 2007-02-09

Tjo, da hilft wohl nur noch /. :) Danke für die Info.

Urban Hillebrand, 2007-02-09

The answer to why this issue happens in OS X's calculator is very obvious if you use the paper tape and set the calculator to it's maximum decimal places.

8511.22 x 1.19 is calculated in one step to give 10128.3517999999985477

8511.22 + 19% is resolved in two steps.

1) 8511.22 * 0.19 giving 1617.1317999999998847 which the calculator truncates to 4 decimal places to give 1617.1318.

2) The paper tape then shows 8511.22 + 1617.1318 giving 10128.3518000000003667

Overall the difference is not 0.04 but 0.000000000001819 all of it attributable to the truncation step used to calculate the value of the 19% in stage 1.

Noel Holland, 2007-02-10

Noel, please watch the second movie and see the different results for German and US locale. This is not a floating point issue.

Volker Weber, 2007-02-10


would this affect traffic?

Giuseppe Grasso, 2007-02-11

Yes. Traffic is up tenfold.

Volker Weber, 2007-02-11

I don't trust that calculator anymore. It ignores decimals in most results on an Intel Mac mini using U.S. English language with Spanish numbering (decimal point is comma).

Guillem Cantallops Ramis, 2007-02-11

A bug you did find, but I would like to comment on your "mark-up" technique, if that what it is. If you really want to make the 19% profit that (which seems to be the case) - you would take your cost number of $8511.22 and divide by .81 - not multiply and get this number $10,507.68. This is due to the fact that you want to make 19% on the total sale number not 19% on the cost of your goods or services. If you continue to use the multiplication of 1.19 technique your actual profit margin will only be 15.966%.

Try the numbers yourself - start with $10.00 cost of goods or services, $10 x 1.2 = $12.00 (profit $2.00) which is 16.666% of the total sale. Now, $10 / .8 = $12.50 (profit $2.50) which is 20% of the total sale. This technique is a large improvement in your profit picture (in this example, an increase in profit by 25%)

This allows to to operate on a gross profit of 20% - the 3.34% difference can make or break a company.

Maybe you know this already, I am just attempting to help you if I can.

Carlton Jackson, 2007-02-11

Nice, but old news. We discussed this already in the forums:

From the number (19%) this is not about the profit. This is about the German tax, which is 19%. So this guy wants to calculate the amount for its invoice he is going to write to its client, which is net + 19%.


Thilo Schumann, 2007-02-11

Hehe, my first submitted story made it to the frontpage. Sorry Volker! :-)

Markus Thielmann, 2007-02-11

PS: This error seems to be related only to the current version (4.0.5) of calculater. Older versions of calculater, e.g. 3.1, do not have this bug.

Thilo Schumann, 2007-02-11

i have an Intel Mac (Core 2 Duo) and get the same error using the % key. However, using .19 instead of 19% always seems to work:

8511.22 * 1.19 = 10128.3517999999985477 (all in one step)

.19 * 8511.22 = 1617.1317999999998847
1617.1317999999998847 + 8511.22 = 10128.3517999999985477 (two steps)

8511.22 + (.19 * 8511.22) = 10128.3517999999985477 (one step w/ grouping symbols)

To me it seems like a grouping symbol problem. When you push the % key, it has to take a percent of something at that moment (it can't just keep .19 in memory and wait for something to multiply it by).

Hope this helps.

Brian DeFreitas, 2007-02-11

I did the same thing you did, and got a difference of 0 between the two methods.

This is on a Core 2 Duo intel iMac, Mac OS X 10.4.8

Mike Smith, 2007-02-11

I'm not sure that I can agree with Volker that it is not a floating decimal point difference. But, it certainly does appear to be a "regional" difference.

Using the United States as the region I get the following: 8511.22 + 19% = 1617.1318; add that amount to 8511.22, and you get 10,128.3518. And, using the U.S. as the region, I also get the following: 8511.22 X 1.19 = 10,128.3518.

The amount of 1617.1318 is precisely 19% of 8511.22; it most certainly is not 1617.09, which is what you get with the German/Germany region calculator.

So, the U.S. region calculator is smart and accurate.

My guess is that for the German region calculator, there is a software problem at the heart glitch.

If you look at Brian's results, where he gets 10128.3517999999985477 in all three tests. But, instead of getting precisely 1617.1318 as he should, he gets 1617.1317999999998847, which is what gives him a result of 10128.3517999999985477.

I could not replicate Noel's results using the U.S. region calculator. Here's what I got with the tape:

8511.22 * 1.19
= 10128.3518


8511.22 + 1617.1318
= 10128.3518

I would certainly like to see one of you get 1617.1317999999998847 as the result of multiplying .19 X 8511.22 by hand instead of the calculator!

Jim Smith, 2007-02-12

Does this effect Grapher too?

Sam Marshall, 2007-02-12

Could this have anything to do with it? That it is actually losing two decimal places of precision by dividing by 100?

Carl Menezes, 2007-02-12

In the second video, while switching locales, the change doesn't not take affect on Calculator till you restart the program. If you restart after switching locales, Calculator should give proper answers.

Sean Nelson, 2007-02-12

It does give proper answers after switching.

Volker Weber, 2007-02-12

I talked with a former Microsoft programmer who wrote the mathpackage in the calculator in Windows. He said that he made the math package keep things in the form of p over q until the last minute, so even before rounding a lot more inverse operations get you to exactly the right number. He also admitted, at my prompting, that In the early days (ha, ha, ha, ha, ha, which meant probably before 1999) the calculator on Windows did have a lot of problems like the Mac, which was in part why he replaced the math package.

He added, "Just for fun try calc -p:100 and take the square root of a number (note that the calc doesn't use any of the floating point package)." Try it on a Mac and then a Windows computer and compare the results.

Jim Smith, 2007-02-12

Or maybe it just doesn't make sense to add 19% to anything. 19% of what?LOL. Let’s hope they keep coming. This could turn into the blonde joke thread II… ;o)

Ben Poole, 2007-02-12

I have a PPC powerbook and the problem still manifests itself.

Does anyone know of a 3rd party Calculator app for OS X that does not suffer these problems?

John Smith, 2007-02-12

I have an intel mac, and it gives me the same result. What r u guys talking about? I'm in the us. and have a 20in intel imac.

Timothy Larsen, 2007-02-12

If you would use the correct decimal point symbol according to your locale settings (dot for US/English, comma for German/Dutch etc) then there would be no problem. It's a user entry bug, not a software bug.

Marc Boon, 2007-02-19

You cannot enter the decimal point on a localized Mac!
You press . on the keyboard and it gives a , in the calculator.

(I use a non-Intel-Mac)

Laurenz Hüsler, 2008-01-22

Try this shareware: CalcExp -- A Powerful Java Science Calculator, Unit/Currency/Color Converter.
It supports formatting result numbers to fitting your locale, 5 locales are supported: English, Germany, France, Italy, US.
It supports 36 functions, 198 units/35 currencies converting, and it has 7 skins.
If you have Java installed on your Mac, just vist the website( and click "Launch", Very Easy!
You have to wait some days for installer for MacOs.

zhiyuan ou, 2008-03-10

8511.22 x 1.19 is calculated in one step to give 10128.3517999999985477
in CalcExp: 8511.22*1.19 = 10128.3518
CalcExp has a precision of 32 digits internally, and use BigDecimal for calculating, so precision is good!
and you can set fraction digits freely from 5 to 16.

zhiyuan ou, 2008-03-10

Old archive pages

I explain difficult concepts in simple ways. For free, and for money. Clue procurement and bullshit detection.


Paypal vowe