Floating point arithmetic.

[Amit Bhatia]

Hi there.
I am restarting this thread as I still can't find a good enough fix for the
problem I am facing:
For example:
double a= 0.15;
double b=2.4;
const double VERYTINY =1.e-10;
I know b/a = 16 and hence the remainder is zero; but I am not
able to find any suitable thing to encode it into in c.
for example (fmod(b,a)>VERYTINY) returns true!
Now for this particular instance, (fmodf(b,a)>VERYTINY)
does return false.
But now if
a=0.15;
b=4.5;
then fmodf and fmod both don't help...

any suggestions on this?
I was pointed to a reference on floating point arithmetic, where they talk
of ulps etc, but is there a small function or fix to deal with this problem
available somewhere?

thanks,
amit.

 

[Ulrich Eckhardt]

I was pointed to a reference on floating point arithmetic, where
they talk of ulps etc, but is there a small function or fix to deal
with this problem available somewhere?

You have to be aware of what is happening, which is why people pointed you
to that reference. You have to be aware of the fact that not every number
can be accurately represented as float or double. Therefore, comparisons
for equality simply don't make sense, as they don't work reliably.

With that in mind, YOU have to decide how to best fit your needs into the
capabilities of your language. I already gave you a hint in
comp.lang.c++.moderated and Mike gave you one here how that could be done,
but the gist is that you have to decide when the difference is small
enough that two numbers can be considered equal.

Let me repeat, there is nothing like THE SOLUTION to your problem. YOU have
decide what makes sense in the context of your application.

Uli

 

[Malcolm]

[ floating point inaccuracy ]

Assume that every floating point operation not involving integers has a
small random error.

The normal way of solving this is to write the program in such a way that
inaccuracies don't matter.

However if this isn't possible, then you can write you own routines that
handle floats as ASCII strings of arbitrary precision. Slow and horrible,
but workable.

 

[Amit Bhatia]

Thanks Guys.
I think I get the idea Better to have things like for loops, etc,
iterated over integers rather than doubles, atleast at places where
differences between doubles may be very small..
As for comparing equality, I think checking the difference between two
values for being relatively very small should do the job for me.
And good programming will of course be a pre requisite.
amit.

 

[Tim Prince]

Hi there.
I am restarting this thread as I still can't find a good enough fix for the
problem I am facing:
For example:
double a= 0.15;
double b=2.4;
const double VERYTINY =1.e-10;
I know b/a = 16 and hence the remainder is zero; but I am not
able to find any suitable thing to encode it into in c.
for example (fmod(b,a)>VERYTINY) returns true!
Now for this particular instance, (fmodf(b,a)>VERYTINY)
does return false.
But now if
a=0.15;
b=4.5;
then fmodf and fmod both don't help...

any suggestions on this?
I was pointed to a reference on floating point arithmetic, where they talk
of ulps etc, but is there a small function or fix to deal with this problem
available somewhere?

Did you mean to use something like
(fmodf(b,a)>VERYTINY*fmax(fabs(b),fabs(a)))
?
In your 2nd example, you have multiplied the relative error in the
representation of 0.15 by 30.

 

[Christian Bau]

Hi there.
I am restarting this thread as I still can't find a good enough fix for the
problem I am facing:
For example:
double a= 0.15;
double b=2.4;
const double VERYTINY =1.e-10;
I know b/a = 16 and hence the remainder is zero; but I am not
able to find any suitable thing to encode it into in c.
for example (fmod(b,a)>VERYTINY) returns true!
Now for this particular instance, (fmodf(b,a)>VERYTINY)
does return false.
But now if
a=0.15;
b=4.5;
then fmodf and fmod both don't help...

"a = 0.15" doesn't set a to exactly 0.15, but to some number very close
to 0.15.
"b = 2.4" doesn't set b to exactly 2.4, but to some number very close to
2.4.

If you divide b/a, then the result is most likely not 16, but a number
very close to 16. It may be a bit larger, it may be a bit smaller. The
result could be exactly 16 on some computers, and not exactly 16 on
others.

Now what is the result of fmod(b, a): b may be a little less or a little
more than 16 times a, or it may be exactly equal to 16 times a. If b is
exactly equal to 16 times a then fmod(b, a) is zero. If b is slightly
larger than 16 times a then fmod(b, a) is a very small number; the
difference between b and 16 times a.

But if b is slightly less than 16 times a then fmod(b, a) is b - 15*a,
and that will be a number just slightly less than a, so it is just a
little bit less than 0.15.