Calculator Broken- this is a good one.

[fenlyn]

Check out this attached file... paper tape can't add or subtract. Perhaps it needs a lesson in basic math.

Brad

[fenlyn]

and this one too!

[j33pd0g]

I don't get it. Are you talking about how the tape doesn't auto round?

[fenlyn]

No... I was figuring out my bills. I found it odd that the calculator display showed the correct answer to my addition and subtraction, but the paper tape is showing an incorrect answer. I never added or subtracted .00000000000001 when I was doing my bills. The fact that the paper tape is not capable of basic math is what I found amusing.

Called Apple about it today, and they said they hadn't even heard of the bug. The support person I was talking to was running 10.3, so I was able to demonstrate it to her. Bug doesn't appear in 10.2... seems like Calculator got a facelift for Panther.

[bousozoku]

It's typical of real (floating point) numbers on computers to be that inaccurate since real numbers cannot be simply described. Most floating point units use the IEEE-754 standard for describing and calculating real numbers but it is built more for scientific calculations.

In fact, most programming languages are incapable of handling money correctly. COBOL and RPG (II/III/IV) have proper types which can be specified with a fixed number of decimal positions that do not falter as do C, C++, Objective-C, Java, etc.

[Wyrm]

I thought it was just a VPC quirk but the same thing appeared in Virtual PC6.1 running Windows2000 under OSX10.3.

On the update it said it had to download something like 15.000000000001 MB

I wonder if there is a problem in OSX?

-Wyrm

[stcanard]

Originally posted by Wyrm
I wonder if there is a problem in OSX?

-Wyrm

Nope, this is a common problem with trying to do decimal arithmetic in binary.

Try representing 0.1 in binary and you'll see the problem.

Better yet, try doing all your math in base 'e'.

Most programs round so you don't notice it, but the inaccuracy is in most programs. If they try to show too many sig figs it will show.

[steadyeddie]

Think yourself lucky... anyone remember when the Windows 95 calculator used to do this:

1.01 - 1 = 0.0

Pretty big rounding error if you ask me!

:D

[Nermal]

I'm running 10.2.8 and have the same problem (Calculator version 3.0).

[johnnowak]

For heaven's sake, every program ever has done this internally.

[rainman::|:|]

i remember this coming up some time ago. not complaining about a dup thread, 'cause this was a looong time ago, just agreeing that it's not a new issue.

pnw

[Powerbook G5]

Originally posted by steadyeddie
Think yourself lucky... anyone remember when the Windows 95 calculator used to do this:

1.01 - 1 = 0.0

Pretty big rounding error if you ask me!

:D

I remember the original Pentium processor had a big error with its math co-processor which led to all kinds of quirks when the first Pentiums came out with Windows 95.

[bousozoku]

Originally posted by Powerbook G5
I remember the original Pentium processor had a big error with its math co-processor which led to all kinds of quirks when the first Pentiums came out with Windows 95.

Right. Most compilers for x86 code generation include a flag to tell the compiler to create FDIV instruction code that is Pentium safe. It was only the first 500 processors but then, the 486s and 386s had divide problems too.

[crash_harddrive]

I just got off the phone with Mac tech support, it seems this is a more common error than I assumed at first. I have a G5 which can't do basic math (and this is in the calculator display, not the tape) but the tech I talked to repeated the problem on a G3 iMac. Seems like a shame that I spent about 4 grand on a computer and now I'll have to spend another $30 on a desktop calculator so I can balance my checkbook. The tech referred me to an article that basically reads "Sorry about your luck", it seems that Apple doesn't find the calculator important enough to fix. BTW, I downloaded two freeware calc apps and both had the same problem so this is a Mac problem in general, not the application. I am at a loss as to why the beast of Redmond can make a working calc program but Apple is clueless. It seems to me that if Apple can't make a working calculator they should leave the app out entirely.

[NuPowerbook]

Originally posted by crash_harddrive
I just got off the phone with Mac tech support, it seems this is a more common error than I assumed at first. I have a G5 which can't do basic math (and this is in the calculator display, not the tape) but the tech I talked to repeated the problem on a G3 iMac. Seems like a shame that I spent about 4 grand on a computer and now I'll have to spend another $30 on a desktop calculator so I can balance my checkbook. The tech referred me to an article that basically reads "Sorry about your luck", it seems that Apple doesn't find the calculator important enough to fix. BTW, I downloaded two freeware calc apps and both had the same problem so this is a Mac problem in general, not the application. I am at a loss as to why the beast of Redmond can make a working calc program but Apple is clueless. It seems to me that if Apple can't make a working calculator they should leave the app out entirely.
As stated, this is a problem with floating point arithmetic. Any calculator program I have made in C++ I have always put error checks in, which isn't that difficult. Also, I believe the reason that you notice in on windowsupdate with Windows under VPC is because of the floating point arithmetic while converting from x86 to PPC. I don't know much about the PPC architecture (new to Macs), but I am also wondering why this seems to be more prevalent in the Mac calculator programs. Are the programmers just lazy in putting in checks for this, or is this an inherent inadequacy of the PPC architecture?

[kevyeung]

I'm running in 10.2.8.
Problem in "Calculator" shared.
"TopCalculette Pro U-3.5" works fine even with paper tape.
Besides, "Graphing Calculator 1.3" in Classic mode also works though there is no traditional paper tape.

;)

[Vector]

I tried doing the same exact calculations and it did them fine. I am using version 3.1.

[NuPowerbook]

Originally posted by Vector
I tried doing the same exact calculations and it did them fine. I am using version 3.1.

Turn on the paper tape, and do the original calculations. It gives the floating point error shown. I am running 3.1 also.

[awulf]

I get this error too in Calculator 3.1, I'm running a G4. I tried the same thing in a Ti-81 emulator but its decimal places doesn't go that far.

[stcanard]

I am surprised that Apple let this through; although this is a common problem in binary arithmetic it's usually handled by taking care of significant digits.

I've now seen the binary precision issue in the regular calculator display. Since it was a completely innocent example (I was doing real math, not trying to break the calculator) I have to believe it will be a regular ocurrence.

Of course, this being OSX, I just avoid it by using xcalc :)

[abhishekit]

well that happens because the precision is set to 12 digits..just goto view-precision and set it to 2..viola it works again...i dont get how this can be considered a bug?!!

[NuPowerbook]

Originally posted by abhishekit
well that happens because the precision is set to 12 digits..just goto view-precision and set it to 2..viola it works again...i dont get how this can be considered a bug?!!

I take it you have never programmed a something that did floating point arithmetic. It's a bug because that's not what the answer is. Do it in your head, on paper, with a handheld calculator, and you will see it is wrong. When doing floating point arithmetic, a lot of casting goes on, so there are inevitable mistakes. Most programmers will take the time to put something in to prevent or catch something like this from happening. Setting the precision to two will only cover it up, not fix it.

[abhishekit]

Originally posted by NuPowerbook
I take it you have never programmed a something that did floating point arithmetic. It's a bug because that's not what the answer is. Do it in your head, on paper, with a handheld calculator, and you will see it is wrong. When doing floating point arithmetic, a lot of casting goes on, so there are inevitable mistakes. Most programmers will take the time to put something in to prevent or catch something like this from happening. Setting the precision to two will only cover it up, not fix it.

yah..never...but anyways i think the guy who started the thread was looking to use the cal and not invent it...

[NuPowerbook]

Originally posted by abhishekit
yah..never...but anyways i think the guy who started the thread was looking to use the cal and not invent it...

I know, but you said it isn't a bug, when it clearly is. I was just explaining why it is a bug.

[iMeowbot]

Originally posted by abhishekit
well that happens because the precision is set to 12 digits..just goto view-precision and set it to 2..viola it works again...i dont get how this can be considered a bug?!!

Floating point math and money really don't mix well, so I'd call it a dubious design choice on Apple's part.

The problem they would have been trying to avoid is that doing arithmetic the same way we would do it by hand (in decimal, and really working with arbitrary length integers -- the decimal point is just a place marker) can be slow for computers to simulate.

On the other hand, a calculator is a perfect candidate for "bigint" math in the REXX tradition, since it's interactive and those delays would go unnoticed.

edit: How to do it right (http://www2.hursley.ibm.com/decimal/)

[kevyeung]

Originally posted by NuPowerbook
I know, but you said it isn't a bug, when it clearly is. I was just explaining why it is a bug.

Please enlighten. When the problem is not found in a 3rd party calculator, does it mean it is not affected OR the problem only confines to the system acessory-calculator ?

[crash_harddrive]

I'm not sure who said a third party calc wasn't affected, I tried two freeware calcs and both duplicated the problem. This isn't a major problem for me but it is a nagging annoyance. I use the calculator mostly for financial purposes so setting the precision to "2" would work for that but all that accomplishes is hiding the problem. The next time I need to use more than two decimal places I'm going to have a hard time trusting my results. So now it seems that there are two things Windows excels at - solitaire and an accurate calculator. Guess I'll keep my 486DX awhile longer.

[Powerbook G5]

Why not just go to Wal Mart and spend $5-15 on a decent calculator? I'm sure it'd be easier than using a software calculator and it'd be more trustworthy.

[stcanard]

Originally posted by crash_harddrive
The next time I need to use more than two decimal places I'm going to have a hard time trusting my results. So now it seems that there are two things Windows excels at - solitaire and an accurate calculator. Guess I'll keep my 486DX awhile longer.

Okay, go back and read this thread again.

There is no problem with the accuracy or correctness of the results.

This is a perfectly good result, based on binary arithmetic, which has the side effect that some fractions that terminate in decimal do not terminate in binary.

Go ask your decimal calculator what 7 / 9 is. Are you really concerned that you are only getting the results to 10 significant digits? How about pi ^2?

If you truly have a need to work accurately to 12 significant digits, go get yourself a library that does arbitrary precision decimal math.

[Nevsan]

I've been programming for awhile and this is a little surprising to me, yet perfectly understandable. Of course it's never been a problem for me since I've pretty much stuck to game programming, but that's cool.

[Mac til death]

download pcalc.... it's really nice

http://www.pcalc.com/

[crash_harddrive]

[QUOTE]Originally posted by stcanard
[B]Okay, go back and read this thread again.

There is no problem with the accuracy or correctness of the results.

This is a perfectly good result, based on binary arithmetic, which has the side effect that some fractions that terminate in decimal do not terminate in binary.

Go ask your decimal calculator what 7 / 9 is. Are you really concerned that you are only getting the results to 10 significant digits? How about pi ^2?

If you truly have a need to work accurately to 12 significant digits, go get yourself a library that does arbitrary precision decimal math.

"No problem with the accuracy or correctness of the results"?
Accurate -
1 : free from error especially as the result of care "an accurate diagnosis"
2 : conforming exactly to truth or to a standard : exact "providing accurate color"
3 : able to give an accurate result "an accurate gauge"
Correct -
1 : conforming to an approved or conventional standard
2 : conforming to or agreeing with fact, logic, or known truth
3 : conforming to a set figure "enclosed the correct return postage"
(Courtesy of Encyclopedia Britannica)
My point here is that this program is NOT accurate and I'm disappointed that Apple refuses to even acknowledge the problem, let alone clean up their act. I consider Apple products to be some of the best on the market but something like this is another black eye just like the recent "white spot" issue with PowerBooks. Apple has a history of refusing to admit mistakes , which is a major slam in the credibility department.

[simX]

Mountain, meet molehill. :rolleyes:

[ElectricSheep]

Okay, this is how floating point numbers work, on every single computer in existance. This is the IEEE standard for binary floating point numbers. The format is thus:

Single Format (standard float)

|s| exp (8) | mantissa (23) |


The 's' is a single bit indicating if the number is positive or negative. The 'exp' is an 8 bit biased exponent. By biased, I mean that whatever numeric representation is in 'exp', the value used in calcuations is going to be exp-127 (for normalized mantissa). The mantissa is the factional part of the exponential, with an implied leading '1' for normalized floats.

So, the number is:

(-1 * s) * (1.mantissa * 2^(exp-127))

Its pretty much like scientific notation.

Floating points, however, have a real hard time dealing with numbers like 92.79. Sure, I can easily represent 92 in binary. Its just 1011100. Nice and exact. The true problem lies in the question: "How do you represent 0.79 in binary?" This is more difficult. The solution in the IEEE specification for floating point numbers is to approximate the decimal fraction with a binary fraction. What's a binary fraction? Its a binary number where each decimal places represents another negative power of two. So, the binary fraction:

0.11001

Is the same as

(1/2) + (1/4) + (1/32)

Trouble is that decimal values like 0.79 require a veritably endless binary fraction to represent. We only have 23 bits in the mantissa to work with. Less, if you consider that the mantissa is normalized, and it contains the representation for 92 as well. So, the best that can be done is to find a close approximation. In the case of 92.79, its floating point representation is:

11000010101110011001010001111011

Where:

1 is the sign bit
10000101 is the exponent (remember, this is biased by 127)
(1.)01110011001010001111011 is the mantissa. The (1.) is implied here.

When we de-bias the exponent, we are left with a value of 6, so we have to shift the mantissa six places to the left to get the represented value:

1.01110011001010001111011 -> 1011100.11001010001111011

So what decimal value does 11001010001111011 represent? Do the math:

(1/2)+(1/4)+(1/32)+(1/128)+(1/2048)+(1/4096)+(1/8192)+(1/16384)+(1/65536)+(1/131072) = 0.7900009155273438

That's not bad, and good enough if all you need is 5 decimal places of precision. But errors like this can compound through time, so if you are working on real mission-critical calculations you can either use longer floating point representations, or implement and arbitrary precision software solution. These libraries are pretty easy to find, and writing one isn't terribly hard. We've all learned the basic algorithms for adding, subtracting, multiplying, and dividing arbitrarily sized decimal numbers: all you have to do is translate that into C or your favorite language.

Calculator isn't advertised as a mission critical arbitrary decimal precision computational tool, nor do I really expect it to implement arbitrary precision libraries.

[cpjakes]

Now how about this problem with Calculator - updating the currency exchange rates. Anyone tried this lately and had a crash? Mine does, on a TiBook 550 with 10.3.3.

I was only trying to figure out what Rosie Reid was worth in USD... :-)

[simX]

Now how about this problem with Calculator - updating the currency exchange rates. Anyone tried this lately and had a crash? Mine does, on a TiBook 550 with 10.3.3.

I was only trying to figure out what Rosie Reid was worth in USD... :-)

This doesn't crash either of my 10.3.3 running computers (I've tested it on a original bondi blue iMac and a 600 MHz G3 iBook).

[cpjakes]

This doesn't crash either of my 10.3.3 running computers (I've tested it on a original bondi blue iMac and a 600 MHz G3 iBook).

Well after a trash of the Calculator prefs AND the financial rate prefs AND a restart, all seems to be fine. Who knows how that got jacked up...

[Zaty]

To get back to the original problem, I just happened to play around with KoalaCalc, it does the math correctly while calculator still displays the incorrect result on the tape. But I reinstalled calculator from the recovery DVD because it wouldn't update the currency conversion rates anymore. So I'm still running version 3.1 (v3.1). Could anyone please check if Apple has updated the calculator at all and if so, have they fixed this problem?

Thanks!

If your're intersted in a freeware calcualar, the above mentioned KoalaCalc is worth trying. It can be found here: http://www.macropodsoftware.com/koalacalc/index.html

[iMeowbot]

So I'm still running version 3.1 (v3.1). Could anyone please check if Apple has updated the calculator at all and if so, have they fixed this problem?
That's still the current Panther calculator, and it still uses floating point arithmetic.

[Zaty]

That's still the current Panther calculator, and it still uses floating point arithmetic.

Thanks for your assistance! I guess Apple won't change the current calculator app, as Tiger is said to ship with a completely different and more powerful app.