double variable question

[polymedes]

Can some body explain to me this:

Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

I don't understand it. Is it the debuger shows me wrong data, or
something i don't know?

[Michael Mair]

polymedes wrote:

Can some body explain to me this:

Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

I don't understand it. Is it the debuger shows me wrong data, or
something i don't know?

The debugger shows you the decimal representation of the binary fraction
stored in the double. If you ask for full precision when using printf(),
you will get the same result.

6.2 is 6+1.0/5, 1.0/5 has no finite representation as binary fraction,
thus you get only an approximation of it. The decimal representation of
0.2 is only finite because 5 is a product of the prime numbers building
up the base 10 (namely, 2 and 5). So, 1.0/(5*5*2) has a finite
representation, but 1.0/3 or 1.0/7 etc has not.

In order to understand the issues at hand better, I suggest some heavy
reading:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

The first sections should be enough for a start :-)
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.

[polymedes]

Michael Mair wrote:

polymedes wrote:

Can some body explain to me this:

Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

I don't understand it. Is it the debuger shows me wrong data, or
something i don't know?

The debugger shows you the decimal representation of the binary fraction
stored in the double. If you ask for full precision when using printf(),
you will get the same result.

6.2 is 6+1.0/5, 1.0/5 has no finite representation as binary fraction,
thus you get only an approximation of it. The decimal representation of
0.2 is only finite because 5 is a product of the prime numbers building
up the base 10 (namely, 2 and 5). So, 1.0/(5*5*2) has a finite
representation, but 1.0/3 or 1.0/7 etc has not.

In order to understand the issues at hand better, I suggest some heavy
reading:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

The first sections should be enough for a start :-)
Cheers
Michael

Thanks a lot Michael. This is really interesting.

[dandelion]

"polymedes" <po*******@nosp am.com> wrote in message
news:cq******** **@nic.grnet.gr ...

Can some body explain to me this:

Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

I don't understand it. Is it the debuger shows me wrong data, or
something i don't know?

Probably the latter.

Floating point numbers (float, double) are not the same as mathematical Real
numbers. Mor specifically, they have a limited precision.

Usually they are represented as mantissa*2^expo nent (instead
ofmantissa*10^e xponent). Now if a certain figure (say 6.2) cannot be
represented that way, the result will be the nearest *) number that can. In
this case 6.1999999999999 993. Now it may look dramatic in your debugger, but
the difference is actually very small.

If you are writing programs using floats or doubles, you should take this
into account. For instance,
comparing two floating point numbers for equality using a blunt "=="
operator is (usually) not a good idea, for the reasons stated above.
Instead, check wether the absolute difference between the two
numbers is less than a specific limit (usually called epsilon).

So nothing bad is happening in your program.

*) Not sure, could be rounded up/down and be implementations specific.

[Martin Ambuhl]

polymedes wrote:

Can some body explain to me this:

Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

I don't understand it. Is it the debuger shows me wrong data, or
something i don't know?

This is the output of a tiny program I just wrote. I am not including
the program, since it would be useful and easy for you to write one for
yourself, just as checking the FAQ before posting is easy. Look
carefully at the output (if you prefer hex, make your program output hex):

On this implementation,
FLT_DIG = 6, FLT_MANT_DIG=24
DBL_DIG = 15, DBL_MANT_DIG=53
LDBL_DIG = 18, LDBL_MANT_DIG=6 4

Showing 6.2f (float) as octal:
6.1463146
Showing 6.1999999999999 993f (float) as octal:
6.1463146

Showing 6.2 (double) as octal:
6.1463146314631 4632
Showing 6.1999999999999 993 (double) as octal:
6.1463146314631 463

Showing 6.2L (long double) as octal:
6.1463146314631 4631463
Showing 6.1999999999999 993L (long double) as octal:
6.1463146314631 4630014

[Gordon Burditt]

>Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

I don't understand it. Is it the debuger shows me wrong data, or
something i don't know?

There is no exact value of 6.2 in binary floating point (nor of
1.8). 0.1 is an infinite repeating decimal in binary. Also,
floating point operations are subject to round-off error.
For example, (1 + 100000000000000 000000) - 100000000000000 000000 has
a darn good chance of coming out zero.

If it's not an exact integer, and it doesn't end in 5 (with trailing
0's removed) it doesn't have an exact representation in binary
floating point.

If it's not an exact integer, has at least two decimal places, and
it doesn't end in 25 or 75 (with trailing 0's removed), it doesn't
have an exact representation in binary floating point.

If it's not an exact integer, has at least three decimal places,
and it doesn't end in 125, 375, 625, or 875 (with trailing 0's
removed), it doesn't have an exact representation in binary floating
point.

It appears that the double value you printed had roundoff error of 1 in the
least significant bit, making it match the 'before' value below:

6.2 as double:
Before: 6.1999999999999 992894572642398 998141288757324 218750000000000 00
Value: 6.2000000000000 001776356839400 250464677810668 945312500000000 00
After: 6.2000000000000 010658141036401 502788066864013 671875000000000 00

6.2 as float:
Before: 6.1999993324279 785156250000000 000000000000000 000000000000000 00
Value: 6.1999998092651 367187500000000 000000000000000 000000000000000 00
After: 6.2000002861022 949218750000000 000000000000000 000000000000000 00

For IEEE doubles, which I suspect you are using, DBL_DIG is 15, and the printed
result is 1 off in the 16th place, so you have nothing to complain about.

Gordon L. Burditt

[Keith Thompson]

polymedes <po*******@nosp am.com> writes:

Can some body explain to me this:

Consider the following code:

int main(int argc, char* argv[]) {
double d1;

d1 = 11.0;
d1 -= 1.8;
d1 -= 3.0; //HERE THE DEBBUGER SHOWS 6.1999999999999 993 !!!

printf("%f", d1); //THE OUTPUT IS 6.200000 (ok, we have less digits)
getch();

return 0;
}

The C FAQ is at <http://www.eskimo.com/~scs/C-faq/top.html>. Read
question 14.1. Then read the rest of section 14. Then read the whole
thing.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.