Does anybody have the slightest idea why when I do this... double a = 123456789.0; double b = floor(a); ...b is 123456789.0 and when I do this... double a = double(1234567.89*100.0); double b = floor(a); ...b is 123456788.0? I noticed this in my program and when I stepped through it, everything checks out, except the floor function. a in the second example is equal to the a in the first example, but for some reason, although the same number exactly, floor returns a different result when the number was previously multiplied. I''m coding an abacus program and I need an exact result. I''ve managed to avoid all round-off errors, but this completely threw me. Thanks for any insight you can provide.

Unfortunately, floating point math is never entirely accurate. The larger your numbers, the worse your precision.

Ok, I''ve been trying more things, and I discovered this too...

I ran this code...

double a, b;
a = 123456789.0;
b = 1234567.89*100.0;
if (a==b)
int a=0; //Just to set a breakpoint on

in the debugger window, both a and b read:
123456789.00000

but the code in the if statement never executes.
The two numbers appear equal but the program doesnt think so. Even if theres a minute difference at the 6th decimal place, I don''t see how that would throw off the floor() function.

PLEASE give me a suggestion!

Thanks!!!

floating point math is by nature imprecise. Only under exceptional conditions should you ever check equality of two floats/doubles. If you need to check whether they''re "close enough", try this:

// numeric limits header has a better version of this, but this''ll work for now#define EPSILON 1e-4if(abs(a-b) < EPSILON){    cout << "They''re equal!\n";} 

---

Don''t listen to me. I''ve had too much coffee.

Thanks, Miserable. That''s what I was afraid of. I''ll just keep trying to find a way around this particular error.

Sneftel, I would normally check if the numbers are close, and the fact that they are very close doesnt bother me. My biggest problem is that whatever tiny difference there is is throwing off the return of floor() by 1. One returns 123456789 and one returns 123456788.

This is a very elementary problem. Because floating point math is not exact (the minute difference at the 6th decimal place that you mentioned - although it would make more sense to talk about significant digits than decimal places due to the nature of floating point math, and also because numbers are not stored in decimal notation), you should never, ever try to compare two floating point values for equality. Instead, check to see whether they are close to some uncertainty (epsilon): Replace (a == b) by (abs(a-b) < epsilon).

I agree with you. I only used the comparison to make sure that there was a difference. I''m aware of the inaccuracies, but I don''t know what causes floor() to be off by so much. If there''s something different in the 6th or beyond decimal place, wouldnt it still be wiped out and return the correct result?

I''m sorry if I''m not seeing this clearly.

Hmm...interesting problem
I guess its the nature of float point math to create a greater margin of error as the number increases in size. I wonder if this problem would be changed if u state the number in notation other than decimal? hex or octal? bin? just an idea

I noticed that ceil() seems to work in place of floor() if used in your examples...unfortunately that may just be dumb luck, plus its not creating the value you want...but maybe us ceil()-1
rather than floor()?

gluck

Thanks. I tried ceil() in place of floor(), but it still seems to have the same error. I''ll definitely try out different notations, and if all else fails, for the delicate calculations, ill just calculate each specific digits in a function. It sure beats answers that are off.

Thanks again for all your replies.