[What they said] Apple calculator a bad joke

Richard Outerbridge writes in on a list I subscribe to to say that the calculator that is part of Apple's latest operating system, Panther, produced wrong results. Here's his post to that list:

The flagship Calculator application that ships with Apple's Panther is so sick as to be shameful.
Two examples:

  • From basic mode enter 12,000,000.
    Go to Convert->Area… Choose “From: Square Inch” and “To: Acre”. Press OK. The displayed result is zero (0). Press '='. The displayed result is 1.44. The correct answer is actually 1.91307009488827.

  • Go to View->Advanced. Try “10000/(2^32)”. The displayed result is 454.5454545454546^32. Press '='. Nothing changes. The correct answer is actually 0.00000232830643.

This could be the first piece of software that someone (that is, Apple) could get sued for, disclaimers of fit-for-purpose,
blah, blah, blah, all to the side.
It's utterly unreliable, yet seemingly so simple, basic and user-friendly!
Apple should make a special out-of-band update to their Calculator, if only to avoid the embarrassment of a prospective Windows switcher finding he can't get a Macintosh to even do basic math correctly, let alone relying on it for doing any “serious” day-to-day work.

One of the great things about Apple's calculator is its conversion engine, a handy tool when you need to do some currency conversion or convert feet to kilometres. If the mistakes discovered by Outerbridge make you nervous, here's an alternative to Apple's tool. It's called ConvertIt. Haven't tried it yet, but it looks promising.

26 thoughts on “[What they said] Apple calculator a bad joke”

  1. Could this be a rounding error issue that is documented
    From Apple Support Pages:
    Mac OS X 10.3: Calculator “Rounding Errors”
    Sometimes, Mac OS X 10.3 Panther Calculator results may include “rounding errors”. Choose a lower Precision setting from the View menu to avoid this issue in the main Calculator window.
    Sometimes you may see different results in the Paper Tape window. For example, if you calculate 77 + .1, the result is 77.1 in the Calculator window as expected; but the Paper Tape window displays a result of “77.09999999999999”.
    Since Calculator uses floating-point arithmetic, the calculation is the expected result. Choose a lower Precision setting from the View menu to avoid this issue in the main Calculator window..

  2. Gee, I don't know if Outerbridge's errors are rounding errors. In the first case, you'd be rounding from 1.44 to 1.9xx. That's not even close. And the second error is a long way off – 454 the power of 32 when the actual answer is is little better than .000002!

  3. There is absolutely no way a rounding error in a single floating-point calculation could cause an error in the first decimal place! That is, with no exaggeration, a million times worse than the Pentium bug. And in the second example, it's an error of 38 orders of magnitude!
    It's pretty clear that Apple's QA has never even glanced at Calculator.app at any point in its life. Here's a much more obvious bug (albeit less serious) that a 5-year-old would have noticed: try entering the number 1.00000002 correctly, on the first try. Not so easy, is it?

  4. Google does conversions.
    Here's an example Google search: “12,000,000 square inches in acres”
    Yields: “12 000 000 (square inches) = 1.91307009 acres”

  5. Under MacOS X 10.2.8 I get different results. (Calculator version is v3.0).
    I get zero (0) as the result of the first calculation of 12 million square inches converted to acres. (The papertape shows the 12000000 is being multipled by zero for the “conversion”.) Huh? At least you'd catch that…
    For the second calculation the result is correct (2.328306436538696e-06). Entered as 10000, /, 2, y^x, 32, =.
    Errors are maybe due to an updated calculator version in 10.3?

  6. These probably are floating point errors. Every floating point value is stored as a fixed precision mantissa and scaling factor. This limits the domain of floating point operations to numbers that are “close.” If you multiply two numbers that have wildly different scaling factors, you'll get completely screwed up results. In the first case, you're multipling 12000000 by 0.236, and the second 10000 by about 0.0000000025.
    This is basic stuff that you need to know for any scientific programming or numerical analysis. There are techniques to avoid these problems, and all of them avoid using standard fixed-precision floating point operations. The author of the Calculator program (which was originally a third-party app called Pcalc) apparently did not do this. It is mind-bogglingly stupid, and hopefully Apple will replace Calculator in Tiger with a program that actually works.

  7. Um, No, Pcalc is a separate program… Pcalc2 is still floating around and was even distributed with Macs a year or so ago…
    BTW: It does fine on the calculations, except it doesn't have the in->acre conversion.

  8. Nope, not floating point errors at all. Look at the paper tape when you run the above calculations. For the first, the conversion routine multiples 12,000,000 by 0.000000, probably some limitation on the significant digits for conversion (I have no idea why). If you press = a second time, it puts the 12000000 after the 0.000000, and 12000000/0.00000012000000 = 1.44. The math is correct, there's just something screwy with the input routines.
    Same problem with the second calculation. As mentioned by one comment above, if you don't use parentheses, the result is as expected (correct). If you do use the parens, the paper tape shows very weird behavior; the (2^32) somehow becomes (22). Again 10000/(22) = 454.545…
    Paul

  9. You've got it completely backwards. Floating point is in fact the best possible representation for multiplying two numbers with wildly different scales (obviously, all you have to do is add the exponents). Adding two numbers with different scaling factors is a problem, but an extremely minor one (truncation error).
    The biggest error comes from subtracting two numbers that are very close together, since there aren't many significant figures to go on to rescale the result. And not a single one of these can possibly explain the pathologically buggy behaviour of Calculator.app.

  10. There is no such thing as View > Advanced in 10.4 right now. I can reproduce the things described, but View > Scientific.
    View menu options are Basic (1), Scientific (2), Programmer (3).

  11. Another serious calculator flaw
    Try calculating 1 ^ 1.23456 (without using logarithms)
    You can't, because the y^x buttond oesn't allow you to enter fractional exponents.
    Actually y^x should have been labelled EE or EXP.
    For some reason Apple has not implemented a real y^x

  12. The conversion problem isn't a math problem or a “rounding” error. It's using the input of 12000000, doing something screwy with scientific notation (1.2e7 becomes 1.2e-7), and using that as the conversion factor.
    If you do the math longhand, it will come out with the correct answer.
    Very untypically sloppy programming on Apple's part.

  13. I tried those conversions in Panther and did NOT have most of those problems. The 2^32 thing gave me the correct answer, and the acres thing never responded with 0.
    The only problem I saw was Apple using 0.00000012 as the conversion from inches to acres. That's not quite accurate, and the difference really multiplies out. So don't use Calculator to convert huge areas from inches to acres. But given that conversion factor, Calculator gave the right result.
    In other words, I see one imprecise (and obscure) conversion preset… and NO arithmetic errors at all.
    Nagromme

  14. Not being funny, but it isn't exactly a major problem. Wanted to know what 12million square inches is acres is hardly an every day occurance.
    Yes okay they should maybe sort these things out, but all these people sifting through endless amounts of maths text books and arguing that someone put a decimal point in the wrong place is just a bit OTT.

  15. BTW, ever thought of using a real calculator for calculating?
    Seems a bit more fitting to me.
    It's not like Calculator is the Core functionality of Mac OS X.

  16. 10000 / (2^anything) produces the exact same results. It always takes the input as 10000 / 22.
    Also try entering 10000/(2^anything + 1). There's something that's just plain screwy with the parentheses.
    If you enter the calculations manually into the paper tape, they all work fine.

  17. Indeed, entering
    1/(2 y^x 2)
    gives something completely wrong. the = is not even necessary. the y^x functionality is definitely broken. it should also accept fractions, btw. the EE key is missing. 🙁 how do i enter 1e-20?

  18. The second issues is definitely not an issue with rounding. Using the unnecessary parenthesis is the source of the problem and required to reproduce it. The “x^y” button applies to the preceding number and is “attached” to the following number entered. The correct answer on both Jaguar and Panther is given if you do not use the unnecessary () buttons.
    The area conversion issues do seem to be directly related to rounding errors. The rounding errors are an absurdity. A calculator application on a modern system uses single precision floating point numbers when there are plenty of arbitrary precision algorithms available is inexcusable.
    Further, the calculator emulates a poor user interface designed from constraints that do not exist on modern computers (and not even modern calculators.) Designing it to look and operate as a 1970's desktop calculator is like emulating typewriter hammers and ink ribbons in a word processor.

  19. The Windows calculator works fine in this scenario with the “unnecessary” parenthesis, and you can open it multiple times.

  20. I have a nice HP calculator(for 15 years) that I would be using right now if the batteries hadn't died. All I was trying to do was balance my check book, I just performed the operation 1056.62-240.0 and got 816.6200000000001 Insignificant I understand, but annoying never the less. And disappointing coming from Apple.

  21. The “Foating Point” stuff is all fixed in the Tiger release of calculator. There is still precision control from 0 – 16, but even at 16, it would display 77 + 0.1 = 77.1
    The conversion, however, is NOT fixed, and is NOT caused by floating point or “Rounding Errors”.
    only a few conversion bugs are related to the floating point bug, while those r fixed, the others remain, i also hear that the graphing hidden plug-in to calculator will be enabled by default in tiger

  22. There's a neat little app called Apples to Oranges that you can download off VersionTracker. It seems to pass your test.

Leave a Reply to Anonymous Cancel reply

Your email address will not be published. Required fields are marked *