Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Possible bug in calculator? Apps
I think I've found a bug in Calculator, at least in OS 10.2.1. It works on two different Macs in my house. Do the following:
  1. Open Calculator.
  2. Click "Paper Tape."
  3. Type in .07 and hit enter or click the equal sign.
  4. The paper tape should display:
    0.07000000000000001    =
    0.07000000000000001
    [Editor: On my calculator tape, this wrapped to two rows]
It also works with 0.56, 85.9, 88.9, and 88.93, and I'm sure there's more. It also works if you add or subtract numbers to reach these numbers. Furthermore, if you do this in Advanced mode, it will actually show "0.07000000000000001" in the readout.

[Editor's note: I seem to remember this being discussed relative to the OS 9 calculator somewhere at some point in time, but I can't find the reference now. It was my understanding that it's not necessarily a bug, given the insignificance of the digit, but rather more of a display glitch. Anyone have a better more technical explanation?]
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[5,759 views]  

Possible bug in calculator? | 22 comments | Create New Account
Click here to return to the 'Possible bug in calculator?' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Minor Problem
Authored by: alexiskai on Oct 09, '02 10:17:45AM

Remember that this is only true for extremely large values of .07. ;)



[ Reply to This | # ]
Minor Problem
Authored by: BigEndian on Oct 09, '02 10:48:14AM

I suspect this has to do with binary to decimal conversion.

When you enter a decimal number (such as 0.07) into the calculator it must convert it to binary (such as 1001101) so it can be used by the processor. Some numbers that are rational in decimal are irrational in binary (an irrational number is one that goes forever, like 1/3 = 0.3333333...).

What this means, is that the calculator is most likely doing the calculation properly (which are done in binary) and is only adding a very small error when it converts to and from binary.

BTW, most calculators work the same way except they round off so you never see the final digit (ie 0.07000000000001 = 0.7)

That's just my opinion, I could be worng...



[ Reply to This | # ]
Minor Problem
Authored by: j-beda on Oct 09, '02 10:56:33AM

Actually, a number is rational if it can be expressed as p/q with both p
and q being integers. Thus 1/3 is rational, and it is still rational when expressed as a decimal 0.33333... Rational numbers expressed as a decimal repeat a patern such as 0.33333... and 0.50000... (sometimes that patern is a bunch of repeating zeros which are usually not written).

Irrational numbers such as pi, e and the square root of 2 cannot be so expressed either as a repeating decimal or as p/q.



[ Reply to This | # ]
Minor Problem
Authored by: j-beda on Oct 09, '02 10:58:29AM

Hey! Where did the comment I was replying to go? Someone had commented that 1/3 was irrational when expressed as a decimal...



[ Reply to This | # ]
Right concept - wrong name
Authored by: avonterr on Oct 09, '02 02:38:51PM

It's not that 0.7 isn't "rational" in base-2, it's that it "doesn't have a finite base-2 expansion." As far as I know, there isn't a widely used one-name word for this category.



[ Reply to This | # ]
Yeah, But the PR Fallout ...
Authored by: Anonymous on Oct 09, '02 10:23:03AM

A little embarrassing, though. Could you imagine if Microsoft decided to roll out their own Switch ads? That same music in the background, and some stoned teenager saying, "Yeah, and when my math teacher said that the answer to 37+37 wasn't wasn't 74.00000002, I realized ... I needed Windows." (Note: I hate M$ and have been a loyal Apple user for three years so far. But this *IS* a bit of a potential PR "d'oh!" for Apple.)



[ Reply to This | # ]
Yeah, But the PR Fallout ...
Authored by: Polemarchus on Oct 09, '02 01:07:20PM

Back in the early 90's, Microsoft had a similar glitch with the calculator provided with Win 3.0 through Win 3.11. In these versions subtracting an integer such as "3" from a decimal like "3.1" would result in an answer of "0"

Personally, I don't have Jaguar yet and so I can't try this out, but what happens when the resultant ".07000000001" is multiplied by 100000000? Does the error remain? Or is it like a previous poster commented only a display glitch?

Even if the problem is more than a display glitch, Microsoft wouldn't be wise to attack Apple on this, since their bug was even more significant valuewise.



[ Reply to This | # ]
Yeah, But the PR Fallout ...
Authored by: weber on Oct 09, '02 06:58:09PM

no, it doesn't carry through the extra digit; apparently it is just a display-only bug.



[ Reply to This | # ]
Yeah, But the PR Fallout ...
Authored by: paploo on Oct 09, '02 04:50:01PM
Since the number holds more digits of precision during calculations, it turns out that 0.07+0.07 is indeed 0.14, not 0.140000...02. Even if you use the memories, so as to actually be using the 0.0700000...01 values.

Indeed, if you program in floating point very often, you'll find that having those little errors like this are actually normal and *extremely* common. However when operations are done with them, things always work out.

I don't know all the details of the whys and hows, but it has to do with the IEEE way in which floating point numbers are represented. Certain exact values are impossible to exactly represent (or something like that). I know that often times the results of calculations give things like 14.9999999999999 or 15.0000000000001. But I'm unsure of any of the details as to why. I'm just vague on this. (Anyone with exacting knowledge care to follow up on this for me?)

Anyway, it is a tad embarrassing that they didn't write complete algorithms to display it as 0.07 instead of 0.0700000...01, but what users don't know (and can't tell), is that that extra algorithms are written to handle displaying the number the way we want to see it. Internally, the floating point variable is still holding the same value.

-Jeff

(I've written a few calculators in my time. :) )

[ Reply to This | # ]

Calm down...
Authored by: kent37 on Oct 09, '02 10:49:51AM
This is typical of floating point on a computer. The problem is that 0.07 does not have an exact representation in floating point. See http://mindprod.com/jglossfloatingpoint.html for a good explanation of this from a Java point of view. And if you add 37 + 37 you should get exactly 74 because there is no fractional part.

[ Reply to This | # ]
Calm down...
Authored by: kp8 on Oct 09, '02 11:19:47AM

It isn't a Mac thang. it is a binary number thing. The best explanation that i found for this is here:

http://www.python.org/doc/current/tut/node14.html



[ Reply to This | # ]
some IEEE math
Authored by: Arakageeta on Oct 09, '02 11:12:50AM

As many have already said, this problem is due to the conversion between a dec based number to a bin based number. Some numbers that can be represented in with finite digits in one base cannot be represented with finite digits in another.

For all floating point numbers, computers conform to the IEEE standard, so just note that there is more involved in coverting a floating point directly to a decimal. The format of the IEEE really isn't important for the following.

Here's a c++ program that takes the number .56 and dumps it's binary value to the screen (in Hex):

#include <iostream>
using namespace std;

int main()
{
double num = .56; // our number -- a 64-bit IEEE floating point
double *d_num = &num; // pointer to that number in memory
int first, second;
first = ((int*)d_num)[0]; // save the first 32bits of the floating point
second = ((int*)d_num)[1]; // save that last 32bits.
printf("%x%x", first, second); // print the integers in hex
return 0;
}

You'll get this on the screen: 3fe1eb851eb851ec

That is our 64 bit floating point number in hex.

NOW, go to this web address: http://www.spatialbase.com/IEEE-754hex64.htm

Paste the hex number we got into the top text field and let the conversions fly!
As you'll see, there's that 0.5600000000000001.



[ Reply to This | # ]
Also...
Authored by: doolio on Oct 09, '02 01:13:10PM

I have also noticed (although I don't know if this is a 'feature') that when Calculator is minimized to only the display window, you cannot drag and relocate it on your desktop.

...weird



[ Reply to This | # ]
Also...
Authored by: UnoAmigo on Oct 09, '02 03:21:13PM

To move it around when it is in display mode - minimize it while it is in display mode, then un-minimise it. You will then be able to move it around. Yes indeed a bug.



[ Reply to This | # ]
What about other digital calculators?
Authored by: jasonxz on Oct 09, '02 01:48:59PM

If this is a decimal to binary conversion problem, then do all digital calculators (including some standalones, like Texas Instruments) have this problem?



[ Reply to This | # ]
Drams
Authored by: xevious on Oct 09, '02 03:29:03PM

When converting from fluid ounces to drams, the conversion factor is 7.999995 although the inverse is 0.125. I looked up the definiton of dram and it should be 1/8 of an ounce.



[ Reply to This | # ]
What about other digital calculators?
Authored by: paploo on Oct 09, '02 04:53:48PM

Yup.



[ Reply to This | # ]
Broken Drams
Authored by: xevious on Oct 09, '02 03:30:42PM

When converting from fluid ounces to drams, the conversion factor is 7.999995 although the inverse is 0.125. I looked up the definiton of dram and it should be 1/8 of an ounce.



[ Reply to This | # ]
Just a radix 2 problem
Authored by: WillyT on Oct 09, '02 11:01:48PM

My old TI99/4A was the ONLY computer I ever had that didn't have this problem. It used 7 digit radix 100 for all math in Basic. So all normal math was wysiwyg. Of course it still had the 1/3 problem? But so did I if I worked it out on paper.
LOL
Willy

ps
I will try to find the old PRECSN program by Mr Nash published in a 1981 "Interface Age". It will discover just what math system you are using.



[ Reply to This | # ]
Even Does This For Paste
Authored by: DVD Plaza on Oct 09, '02 11:30:22PM

As you no doubt know, you can copy and paste figures from/to the OSX calculator. However last night I ran into something weird - I pasted a figure into the calculator (say 1429.07) and it instead created some weird variation like 1429.0699999!!! WTF?!?



[ Reply to This | # ]
Bad calculator design
Authored by: wkunz on Oct 10, '02 04:48:23AM

As several people have pointed out, these non-zero digits way behind the decimal point are normal in floating-point binary-to-decimal conversions. Modern calculators don't show these digits because they do the calculations using two or more digits than are shown on the display. You can still see "wrong" results sometimes in old or cheap models.
One way to avoid conversion errors is to implement the floating-point routines using BCD (binary-coded-decimal) digits, where each digit 0..9 is encoded as a 4-bit number. I worked with such packages back in the homebrew computer era (i.e. the late 70's). One reason this method is used rarely is that it's slower than pure binary math and it's less standardized (if at all, I'm not sure about that).
So the "bug" described is not really a bug but the consequence of bad calculator design. The calculator is showing too many digits. Hiding one or (better) two digits would result in a very precise calculator.



[ Reply to This | # ]
Only Happens in Advanced Mode
Authored by: slimpy on Oct 10, '02 03:34:02PM

I came across this problem about a week ago when multiplying 0.05 x 0.75 with the result being: 0.03750000000000001. It was a bit confusing at the time... but I later discovered that the problem only occurs in advanced mode. Hope this helps a bit.



[ Reply to This | # ]