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:
Comments
That won't bother any Mac user, as long as it looks cool ;-)
Good to have a windows box. There's no %-button in calc.exe ;-)
Ralf, there is one, but only in standard view
Well, I get the same results.
The Microsoftie calculator also has no sqaure root key.
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?
Dear admin, could you please edit my previous post to nail down the typos/horrible english.
You should never write vowe with a capital v. :-)
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).
Ah, good old Intel... Works fine and consistently on PPC
Ben, you nailed the problem. It gives you 1617.09.
Well, that sure must be a side-effect of the Core Duo's inferior floating point capabilities;-)
Google would've worked fine if you would have done 8511.22 * 1.19 or
8511.22 * 19% + 8511.22
Can somebody try this on Excel on the Intel Mac?
I have. This is not a CPU bug. Only Calculator is affected.
Volker, you're sure you got no Pentium under the hood? ;-)
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,
Was Parallels running Windoze? ;-)
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 :)
Maybe the calculator has a problem with the comma as decimal delimiter.
As for the screen captures, Snapz Pro is an excellent choice IMHO.
You've got heised:
http://www.heise.de/newsticker/meldung/85048
You've got heised.
You've got heised.
Because it's Friday! :-)
Schau mal auf den Autor der Meldung. :-) Den Link hat allerdings jk eingebaut.
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...)
Funktioniert auch in den NL, auch hier rechnet der Mac flsach...
Neugierige Frage an Volker: Wie sehr wirkt sich eigentlich die Heise-Meldung auf die Zugriffsstatistik aus?
Macht eine kleine Delle in der ersten Stunde. Über den Tag gerechnet sind es etwa 5% mehr Zugriffe.
Tjo, da hilft wohl nur noch /. :) Danke für die Info.
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, please watch the second movie and see the different results for German and US locale. This is not a floating point issue.
digged!
http://digg.com/apple/Mac_Calculator_is_bad_at_math
would this affect traffic?
Yes. Traffic is up tenfold.
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).
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.
Nice, but old news. We discussed this already in the forums: http://www.macuser.de/forum/showthread.php?t=211507
@Carlton
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
Hehe, my first submitted story made it to the frontpage. Sorry Volker! :-)
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.
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.
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
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
and
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!
Does this effect Grapher too?
Could this have anything to do with it? That it is actually losing two decimal places of precision by dividing by 100?
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.
It does give proper answers after switching.
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.
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)
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?
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.
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.
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)
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(http://www.calcexp.com) and click "Launch", Very Easy!
You have to wait some days for installer for MacOs.
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.