[Eug]

sin-1 of 1 = 89.99999998824843
cos-1 of 0 = 89.99999998824843
tan-1 of 1 = 44.99999999412422

sin 90 = 1
cos 90 = -2.051034285153312e-10
tan 45 = 1.000000000205103

Huh? Not that this is a big deal for me, since I haven't used my trig in about 10 years, but I wonder what else is wonky with the calculator.

[placebo1969]

Yeah, try this:
1-.9-.1=
Should be 0, of course, but it isn't.

[snerdini]

Wow. There is something very wrong with Calculator. Didn't realize it until now...

[The Godfather]

It is the G4 math bug! RUn!

[diamondsw]

Just the simple reality of floating point math - it makes slight errors like this all the time. "Real" mathematics packages generally use custom internal formats that can properly represent precise numbers and symbolic values. Everything else just uses floats, which since they store only a certain amount of precision, lose some data with every calculation.

Just a fact of life.

[CyberDave]

Originally posted by diamondsw:
Just the simple reality of floating point math - it makes slight errors like this all the time. "Real" mathematics packages generally use custom internal formats that can properly represent precise numbers and symbolic values. Everything else just uses floats, which since they store only a certain amount of precision, lose some data with every calculation.

Just a fact of life.

Binary representation of fractions is not entirely accurate. Binary uses powers of 2. Each digit of a binary number represents the coefficient of 2^i for bit position i (numbering starts at 0 for the position immediately to the left of the radix point and increase to the left and decrease to the right).

In English: each fraction must be represented by some combination of whose denominators are powers of 2 and whose numerators are either 0 or 1. Not all fractions can be represented in this manner with 100% accuracy. Even those that can may require more bits than the standard 32-bit and 64-bit IEEE 754 formats for floating point numbers. Thus, some accuracy is lost as the bits are truncated to fit into the formats.

That's the short version of it.

CyberDave

[CyberDave]

For those that really care (and those like me who are looking for some excuse to put some of my really boring CS class material to use)...

The IEEE 754 32-bit single-precision floating point numbers use 1 bit for the sign, 8 bits for the excess-127 representation of the exponent (with 00000000 and 11111111 being reserved for special cases), and 23 bits for the base-2 fraction. There is an implied 1 to the left of the binary point.

The 64-bit double-precision floating point numbers use 1 bit for the sign, 11 bits for the excess-1023 representation of the exponent (with all 0's and all 1's being reserved for special cases) and 52 bits for the floating point representation of the base-2 fraction.

CyberDave

[Detrius]

Note that 23 bits for the data means that everything after about 6 or 7 digits back from the big end of the number is lost. Since decimal fractions aren't represented in binary anywhere nearly as easily as integers are, this means that simple math like 1.0-.9-.1 may come out to about .0000001. This is where it looks like the precision is lost, so this is as expected with ANY processor.

[Eug]

Originally posted by Detrius:
Note that 23 bits for the data means that everything after about 6 or 7 digits back from the big end of the number is lost. Since decimal fractions aren't represented in binary anywhere nearly as easily as integers are, this means that simple math like 1.0-.9-.1 may come out to about .0000001. This is where it looks like the precision is lost, so this is as expected with ANY processor.

OK, you people are over my head. I'm not a computer person, nor am I a math person. (It's too bad too, since logistic regressions I'll need to be doing have got me by the 'nads. )

However, neither my Windows NT calculator nor my $20 standalone calculator have this problem. (And the sin cos problem is not there with those either.)

Also, what I don't understand is why sin 90 on the OS X calculator gives the right value of 1, whereas the other calculations are slightly off. I'll have to try the 1 - 0.9 - 0.1 thing when I get home. If that's incorrect, that's unacceptable IMO.

[CyberDave]

Originally posted by Eug:
Also, what I don't understand is why sin 90 on the OS X calculator gives the right value of 1, whereas the other calculations are slightly off. I'll have to try the 1 - 0.9 - 0.1 thing when I get home. If that's incorrect, that's unacceptable IMO.

It's not unacceptable; that's exactly how it is supposed to work with ANY computer that stores decimal numbers (base 10) in binary format (base 2). That's the whole point. It's simply not possible to get !00% accuracy in binary format unless you have a virtually infinitely long binary number (which in turns consumes a virtually infinite amount of memory and CPU time). Some calculators (both software and hardware) just do a better job of hiding this lack of precision than others (some HP calculators for example don't actually use straight binary encoding, they use BCD (Binary Coded Decimal) to do store numbers, but this is a completely different method of binary representation and has other issues).

CyberDave

[msykes]

Okay, I really have to take this opportunity to plug "Menulator", which I did NOT write, but just happen to think is marvelous.

Little menu bar calculator, doesn't have any of these problems as far as I can tell, and even graphs functions in a pinch.

http://www.versiontracker.com/morein...d=14818&db=mac

And go ahead and submit some feedback to Apple about your sucky Calc experiences, they should be able to remedy that fairly easily.

[bewebste]

They should just use doubles instead of floats. That would make for a much smaller margin of error.

[Eug]

Originally posted by CyberDave:


It's not unacceptable; that's exactly how it is supposed to work with ANY computer that stores decimal numbers (base 10) in binary format (base 2). That's the whole point. It's simply not possible to get !00% accuracy in binary format unless you have a virtually infinitely long binary number (which in turns consumes a virtually infinite amount of memory and CPU time). Some calculators (both software and hardware) just do a better job of hiding this lack of precision than others (some HP calculators for example don't actually use straight binary encoding, they use BCD (Binary Coded Decimal) to do store numbers, but this is a completely different method of binary representation and has other issues).

CyberDave

OK then, Apple needs to do a better job of "hiding" this problem. The Windows NT calculator for example gives results up to something like 32 digits, but does not seem to suffer the problem the Apple OS X does.

I could see the square of the square root of 2 not equalling 2 for example, but it's bizarre not to have 1 - 0.9 - 0.1 = 0. (I've yet to try this calculation on my Mac though.)

By the way, the Windows calculator may be "hiding" stuff, but for instance:

tan (45.0000000000000000000000000001) = 1.0000000000000000000000000000035

but tan (45) = 1

Is the amount of precision in the Apple Calculator simply lower?

[K++]

I guess there's a reason why Apple includes PCalc nowadays seeung as how Calculato ris so "unacceptable"

[gorgonzola]

Originally posted by msykes:
Okay, I really have to take this opportunity to plug "Menulator", which I did NOT write, but just happen to think is marvelous.

Little menu bar calculator, doesn't have any of these problems as far as I can tell, and even graphs functions in a pinch.

http://www.versiontracker.com/morein...d=14818&db=mac

And go ahead and submit some feedback to Apple about your sucky Calc experiences, they should be able to remedy that fairly easily.

Not really relevant, but that was written by a MacNN Staffer. Just thought I'd plug MacNN.

[Eug]

Originally posted by Karl Snyder:
Yeah, try this:
1-.9-.1=
Should be 0, of course, but it isn't.

Yep. I get -2.775558e-17.

I just tried Menulator and it has the same problem:
1-0.9-.1 = -2.77555756156e-17.

And Pcalc 2.2.2 has the same problem (although it doesn't have the sin cos issues).

WTF?

[CharlesS]

Originally posted by Eug:

Yep. I get -2.775558e-17.

I just tried Menulator and it has the same problem:
1-0.9-.1 = -2.77555756156e-17.

And Pcalc 2.2.2 has the same problem (although it doesn't have the sin cos issues).

WTF?

It's due to the already-mentioned precision problem with floating point math. To confirm it, I just wrote a quick C command-line program to perform 1.0 - 0.9 - 0.1. Using doubles, I get the result everyone else has been getting, -2.775558e-17. Using floats, it's worse - I get 2.235174e-08. If I print the result using plain old %f, it gets rounded to zero and is fine - it's when I display it in exponential notation using %e that there's a problem.

On the bright side, at least we now know that Calculator.app is indeed using doubles.

[Eug]

Interesting.

I wonder what the Windows calculator program is doing differently since it does not suffer this same problem.

Also I wonder why Pcalc doesn't give me 89.99999etc when doing the sin-1 of 1. It gives me 90, as expected.

By the way, in OS X Calc: 1.414213562373095 x 1.414213562373095 = 2

On my PC it equals 1.999999999999999861967979879025

On the PC if I calculate the square root of 2 and then square the result, I get 2.

On the PC if I calculate the square root of 2 and then copy it to the clipboard, clear the calculator memory, and the square that value in the clipboard, I get 1.9999999999999999999999etc.

[placebo1969]

Apparently the Calculator application has had this issue since 1984. (Probably earlier with Lisa.) Regardless of the technical reasons why the problems exist, it still is there and Windows doesn't have the problems. That's the frustrating part.

[CharlesS]

Originally posted by Eug:
Interesting.

I wonder what the Windows calculator program is doing differently since it does not suffer this same problem.

Also I wonder why Pcalc doesn't give me 89.99999etc when doing the sin-1 of 1. It gives me 90, as expected.

By the way, in OS X Calc: 1.414213562373095 x 1.414213562373095 = 2

On my PC it equals 1.999999999999999861967979879025

On the PC if I calculate the square root of 2 and then square the result, I get 2.

On the PC if I calculate the square root of 2 and then copy it to the clipboard, clear the calculator memory, and the square that value in the clipboard, I get 1.9999999999999999999999etc.

Probably just because the PowerPC and Pentium processors use different floating-point units which work differently.

[barney ntd]

Real numbers are formally uncomputable. This means that there is no way to represent them without problems.

• The Mac calculator is behaving correctly according to the IEEE floating-point specification, which is the specification used by all floating-point units in all current microprocessors. The problems you are seeing are typical of the conversion from decimal to binary.
• The BCD representation used by some calculators is much better at coping with decimal problems (like 1-0.9-0.1) but it's less efficient (in both memory and speed) and is just as bad with anything not an exact decimal (like 1/3).
• Mathematica (the top commercial mathematics package) uses an arbitrary length decimal, i.e. a string of digits, all of which are guarenteed correct. This fixes the simple problems mentioned here, but it's very slow, and calculations tend to reduce the length of the answer (as accuracy is lost) until you have nothing left.
• As someone mentioned above, some packages use symbols to represent exact values, and compute by simplifying formulae. I know of a commercial postscript engine which does this to improve print quality. This is limited by the rules used to simplify the expressions: the more symbols you add, the more complicated the rules become. Ultimately, you have to calculate with numbers to get the answer.
• Several academics are working on implementations of "exact arithmetic". Using various unusual representations of numbers as data-streams, it is possible to calculate all the usual functions precisely. People are still arguing about how efficient this can be, though it is certainly less than floating point. The real disadvantage is that it is impossible (in general) to tell whether two numbers are equal, or whether a number is zero, so you can't even check for divide by zero errors!

For every day problems, floating point seems to be the best compromise.

Barney.

[Eug]

Hmmm... This subtraction issue WAS a problem in older versions of Windows.

In Windows 3.0: 12.52 - 12.51 = 0.0099999999

However, it was corrected in later versions of calc.exe in Windows 3.1.

Also, Calculator changes in Windows NT 4 SP4:

"Extended Precision, a new feature of Calculator, means that all operations are accurate to at least 32 digits. Calculator also stores rational numbers as fractions to retain accuracy. For example, 1/3 is stored as 1/3, rather than .333. However, errors accumulate during repeated operations on irrational numbers. For example, Calculator will truncate pi to 32 digits, so repeated operations on pi will lose accuracy as the number of operations increases."

[Eug]

Originally posted by Eug:
Hmmm... This subtraction issue WAS a problem in older versions of Windows.

In Windows 3.0: 12.52 - 12.51 = 0.0099999999

However, it was corrected in later versions of calc.exe in Windows 3.1.

Also, Calculator changes in Windows NT 4 SP4:

"Extended Precision, a new feature of Calculator, means that all operations are accurate to at least 32 digits. Calculator also stores rational numbers as fractions to retain accuracy. For example, 1/3 is stored as 1/3, rather than .333. However, errors accumulate during repeated operations on irrational numbers. For example, Calculator will truncate pi to 32 digits, so repeated operations on pi will lose accuracy as the number of operations increases."

Well, the issue still persists with OS X.2.3's calculator.

I guess I will continue to use the Windows calculator for simple arithmetic.

[Emotionally Fragile Luke]

Oh lord.

[brachiator]

Well, its certainly hella bad for P.R.... Apple should implement something to at least bring it up to the apparent level of accuracy of the Windoze app. Just what we don't need is another real or perceived Trent-Lott-aspect of the OS or PPC...

Thanks for the lessons on how numbers and math are dealt with, though. At least the .00000001 % (rounded ) that I understood, was quite interesting.

Mike

[ambush]

KellyHoogan / GreenLeaf didn't post yet? WTF? OMG! BBQ!

[TheIceMan]

Originally posted by Karl Snyder:
Yeah, try this:
1-.9-.1= Should be 0, of course, but it isn't.

Man, you're right. Even weirder is that:
1 - 0.1 - 0.9 = 0 I didn't think this would matter that much. But I actually use my OSX calculator frequently. I can't believe that these problems are still there in 2002 (almost 2003 from the 10.2.3 update). Geez, if the original calculator was written in 1984 and it's hasn't been corrected. This is bad for Apple. Well, gotta go send an email letting them know about this. Tsk. Tsk

Ok, I emailed Apple about this. I told them that we are proud of our computers/laptops AND that we paid alot for them SO we expect and DEMAND better. I also told Steve Jobs that "it's time to go to work" and correct this. I guess we'll wait and see.

[Wevah]

Does anyone besides me use bc from the command line? You can set its precision to an arbitrary value...mmm.

[Angus_D]

This was discussed a long time ago, around the release of 10.2. If this was a proper calculator program, it would do rounding and checking to hide the problem from users... However, it's just a free little utility and Apple obviously hasn't spent that much time on it

[brachiator]

Originally posted by ambush:
KellyHoogan / GreenLeaf didn't post yet? WTF? OMG! BBQ!

... teleconference with ShyWizard. Give it time...

[Eug]

This has all been corrected in X.3. There's more to the new calculator than just a metal facelift.

And 1/0 = "Infinity".

[exca1ibur]

Originally posted by Karl Snyder:
Yeah, try this:
1-.9-.1=
Should be 0, of course, but it isn't.

Worked fine for me. I get 0 here running 7B85. Hmmm.

[Eug Wanker]

exca1ibur, the problems seem to have been fixed in Panther.

[michael_on_mac]

Originally posted by Wevah:
Does anyone besides me use bc from the command line? You can set its precision to an arbitrary value...mmm.

Me, I do. Don't trust Apple with these things... it's a pity.

Now, what about dc? It's an rpn calculator, you know it?

Best,
Michael.

[- - e r i k - -]

I get 1,0-0,9-0,1=0 in Calculator. This issue is fixed in Panther.

[Eug Wanker]

Hmmm... I guess it's not completely fixed in Panther.

[wadesworld]

I'm not a math guy, but what I'm hearing is this:

1) Both Windows and Macintosh suffer from the same issues.

2) The issues are not bugs at all. They are the reality of floating point math on Intel and PowerPC.

3) Windows, has done some special coding to make the values appear "more correct" to those that don't understand the issues involved. But it's just window dressing - Windows is no more accurate.


Wade

[Cadaver]

This can be "fixed" by reducing the number of decimal precision on the Panther calculator. It defaults to 12. Change it to something lower (for me, all I need is 5 decimals) and it doesn't give the rounding "errors".
To save your selection, use cmd-W instead of Quit or the red close button on the calculator.

[Eug Wanker]

Originally posted by wadesworld:
I'm not a math guy, but what I'm hearing is this:

1) Both Windows and Macintosh suffer from the same issues.

2) The issues are not bugs at all. They are the reality of floating point math on Intel and PowerPC.

3) Windows, has done some special coding to make the values appear "more correct" to those that don't understand the issues involved. But it's just window dressing - Windows is no more accurate.

1) Both Windows and Mac OS suffer from the same issues, but Windows suffers a lot less.

2) The issues are not bugs, depending upon the method of programming used. But there are widely available methods for addressing some of these issues, so these bugs are not the reality of decimal math on PowerPC and x86 (according to the guys who do math programming).

3) Windows has done some special coding, sometimes just to make things look better I believe, but also sometimes to actually give the correct value. See #2 above.

Anyways, this is what I get with Panther:

Originally posted by Cadaver:
This can be "fixed" by reducing the number of decimal precision on the Panther calculator. It defaults to 12. Change it to something lower (for me, all I need is 5 decimals) and it doesn't give the rounding "errors".
To save your selection, use cmd-W instead of Quit or the red close button on the calculator.

The paper tape will still show the incorrect numbers.

[chabig]

Part of the problem is that most people don't understand the concept of significant figures and think that if the calculator shows 16 digits they are all significant, regardless of the number of significant figures in the operands. This is not correct.

Chris

[Ganesha]

Being a scientist, the last thing I want my software to do is randomly decide to round a number because the software thinks it should be an integer or whatever. As, a scientist, I *hopefully* should know many significant digits to take.

[Richard Edgar]

Anyone who thinks that asin(1) is anything other than ( (\pi / 2) + 2 n \pi ) for integral n has no business complaining about an error in the seventh or eighth significant figure.

As pointed out above, floating point arithmetic is inexact. Getting very precise results is very hard - and saying that using doubles instead of floats can make problems go away is pure ignorance. It might be good if Apple were to fix the problem (or at least give the illusion that it is fixed), but no one who cares about accuracy on that level is going to be using the calculator application anyway. So why bother?

[CharlesS]

Originally posted by Richard Edgar:
Anyone who thinks that asin(1) is anything other than ( (\pi / 2) + 2 n \pi ) for integral n has no business complaining about an error in the seventh or eighth significant figure.

As pointed out above, floating point arithmetic is inexact. Getting very precise results is very hard - and saying that using doubles instead of floats can make problems go away is pure ignorance. It might be good if Apple were to fix the problem (or at least give the illusion that it is fixed), but no one who cares about accuracy on that level is going to be using the calculator application anyway. So why bother?

Apple is already using doubles instead of floats, as I showed above (in this very old thread!)

[Richard Edgar]

Apple is already using doubles instead of floats, as I showed above (in this very old thread!)

That isn't relevant to the points I made. The same could be said of double vs quadruple precision arithmetic.

[Twilly Spree]

Here is a question for you programmers: How come they have to use floating point calculations in the Calculator app?

What did they use before FPU was a part of the processor (like in the 68000)

[shortcipher]

I think what Eug is complaining about is that if a common or garden pocket calculator can get this seemingly right (irrespective of the various computing issues of fractional numbers) then the OSX calc should be able to do it as well.

Its obvious that fractions such as 1/3 cannot be represented exactly using decimals, but it makes very little sense that non recurring decimals have the same problem, after all if 100-90=10 then why does 1-0.9=0.999999?

Anyway, I think OSX10.3 has got it right, the calc is supposed to be a consumer friendly simulation of a physical device, these supposed "inaccuracies" should be hidden from the user.

[Richard Edgar]

What did they use before FPU was a part of the processor (like in the 68000)

Software emulatiom. IIRC, the early ARM chips didn't even have an integer divide instruction on the silicon.

Its obvious that fractions such as 1/3 cannot be represented exactly using decimals, but it makes very little sense that non recurring decimals have the same problem, after all if 100-90=10 then why does 1-0.9=0.999999?

Leaving the obviously dodgy arithmetic aside, since when have computers worked with decimal numbers? It is possible to do BCD, but far from normal. As an exercise, try writing (1/10) as a sum of 2^{-n}.

[Eug Wanker]

Originally posted by shortcipher:
I think what Eug is complaining about is that if a common or garden pocket calculator can get this seemingly right (irrespective of the various computing issues of fractional numbers) then the OSX calc should be able to do it as well.

Its obvious that fractions such as 1/3 cannot be represented exactly using decimals, but it makes very little sense that non recurring decimals have the same problem, after all if 100-90=10 then why does 1-0.9=0.999999?

Anyway, I think OSX10.3 has got it right, the calc is supposed to be a consumer friendly simulation of a physical device, these supposed "inaccuracies" should be hidden from the user.

Actually, they aren't hidden from the user - see paper tape above.

By the way, what does OS X do in this case (I don't have my TiBook here):

From the Windows 2000 Calculator:

Understanding extended precision

Extended Precision, a feature of Calculator, means that all operations are accurate to at least 32 digits. Calculator also stores rational numbers as fractions to retain accuracy. For example, 1/3 is stored as 1/3, rather than .333. However, errors accumulate during repeated operations on irrational numbers. For example, Calculator will truncate pi to 32 digits, so repeated operations on pi will lose accuracy as the number of operations increases.

This is what Windows 2000's Calculator does:

1 - 0.333333333333333333333333333333 - 0.333333333333333333333333333333 - 0.333333333333333333333333333333 = 0.000000000000000000000000000001

However, if you divide 1/3 and store the result in memory and do 1 - memory - memory - memory you get 0.

ie. In Windows, 1 - 1/3 - 1/3 - 1/3 = 0, as it should. The same is true for my $4 calculator.

[shortcipher]

Originally posted by Eug Wanker:
Actually, they aren't hidden from the user - see paper tape above.

By the way, what does OS X do in this case (I don't have my TiBook here):

Yes, I know, but its mostly hidden for users who arent really looking for it.

In OSX, 1/3*3=1, so calc is obviously storing a more complete description of the number than what you can see in the display (0.3333333333333333), however if you type the same number in manually and multiply by 3 you get 0.999999999999, which is what I would expect.

This whole issue is very weird and I dont profess to fully understand why non-recurring decimals are so hard to represent (perhaps I am misunderstanding though) however it seems to me that in most circumstances you want the "intelligent" behaviour as demonstrated by calc, even in programming languages such as Javascript/Flash or whatever, the user should be shielded from this type of strangeness as it does them no benefit to have to deal with it. Other languages are undoubtedly different, so please dont flame me. ;-)

[Eug]

Yeah, I've been playing some more, and it seems 1 - 1/3 - 1/3 - 1/3 works fine in OS X too, but I could have sworn somebody said it didn't. Maybe that was with X.2 or something I dunno.