Calculator bug?

[Nermal]

Calculator (v3.1) just gave me an interesting result.

10339.01 + 66231.9 = 76570.90999999999

 

[yellow]

There's lots of articles out there about it..

http://www.google.com/search?hl=en&lr=&q=mac+os+x+calculator.app+bug&btnG=Search

 

[jared_kipe]

Oh no, not a repost, please save us all of you who can do searches. It isn't that big of a deal, if you don't like the reposts then don't read them. But yes, calculator is crafty some times.

 

[russed]

i think that prob should be fixed when 10.3.6 comes out soon. that is one of the areas that is being updated.

 

[MisterMe]

Calculator (v3.1) just gave me an interesting result.

10339.01 + 66231.9 = 76570.90999999999

The result may be "interesting," but it is not "wrong."

 

[Nermal]

Oh no, not a repost, please save us all of you who can do searches. It isn't that big of a deal, if you don't like the reposts then don't read them. But yes, calculator is crafty some times.

Yeah, sorry, I didn't search because I was doing a non-resumable download at the same time, so browsing was like being back on a 14.4 modem again

The result may be "interesting," but it is not "wrong."

Care to explain how that is not wrong? Sure, it's correct if you round it, but if you don't round it then it certainly is wrong!

 

[Freg3000]

Care to explain how that is not wrong? Sure, it's correct if you round it, but if you don't round it then it certainly is wrong!

Under the theory that
1/3 = .33333333 non-terminating,
2/3 = .66666666 non-terminating,

so 1/3 + 2/3 = .99999999999 non-terminating = 3/3 = 1

76570.90999999999 = 76570.91

That's what I think he meant anyway.

 

[MisterMe]

....

Care to explain how that is not wrong? Sure, it's correct if you round it, but if you don't round it then it certainly is wrong!

Freg3000 is on the right track. What you see as a bug is merely the age-old artifact of doing floating-point decimal math in binary. Hardware calculators usually do math in binary-coded decimal. Computer-based calculator emulators usually do math in binary and then convert the result to decimal. This conversion step may introduce the string of 9's. Apple's programmers have chosen not to round-off the result, but the answer is correct to the proper number of significant figures.

 

[jeremy.king]

Freg3000 is on the right track. What you see as a bug is merely the age-old artifact of doing floating-point decimal math in binary. Hardware calculators usually do math in binary-coded decimal. Computer-based calculator emulators usually do math in binary and then convert the result to decimal. This conversion step may introduce the string of 9's. Apple's programmers have chosen not to round-off the result, but the answer is correct to the proper number of significant figures.

Yes, those numbers are represented in binary in memory, but the inaccuracy is not the fault of binary arithmetic. It has to do with the fact that a calculater/computer only have a fixed (finite) amount of memory to represent a floating point number, so some precision is lost.

 

[molcas&e'sdad]

I think that I find a "bug" in calculator every time I try to balance my checkbook ...

 

[MisterMe]

Yes, those numbers are represented in binary in memory, but the inaccuracy is not the fault of binary arithmetic. It has to do with the fact that a calculater/computer only have a fixed (finite) amount of memory to represent a floating point number, so some precision is lost.

Handheld calculators have much less available memory than just about any computer-based calculator.

 

[Nermal]

As of version 3.2 (included with 10.3.6), it now works as expected

 

[jeremy.king]

Handheld calculators have much less available memory than just about any computer-based calculator.

not total memory...but allocated memory In most cases calculators have the same precision as a computer - 64 bit decimal representation, unless you are using customized data types - such as BigDecimal in Java...