Problem with accuracy in DEV C++

  • Thread starter Hatzigiannakis Nikos
  • Start date
H

Hatzigiannakis Nikos

In the following code

main()
{
double x;
for (x=0.0;x<=1;x=x+0.05)
{
printf("x=%6.3f \n",x);
}
}

I receive numbers from 0 to 0.950. 1 is not included. I understand that it
is an accuracy problem but how can I solve it ?
 
B

Bartc

Hatzigiannakis Nikos said:
In the following code

main()
{
double x;
for (x=0.0;x<=1;x=x+0.05)
{
printf("x=%6.3f \n",x);
}
}

I receive numbers from 0 to 0.950. 1 is not included. I understand that it
is an accuracy problem but how can I solve it ?

Try changing double to float. And the 6.3 to something like 6.10. Also
temporarily change the x<=1 to x<=2:

float x;
for (x=0.0;x<=2;x=x+0.05)
{
printf("x=%6.10f\n",x);
}

Then hopefully you will see what the numerical problem is and can see a way
of fixing it.

You might see that when x gets to near 1.0, it will actually be slightly
more than 1.0, so that x<=1 will fail.
 
C

CBFalconer

Hatzigiannakis said:
In the following code

main() {
double x;
for (x=0.0;x<=1;x=x+0.05) {
printf("x=%6.3f \n",x);
}
}

I receive numbers from 0 to 0.950. 1 is not included. I understand
that it is an accuracy problem but how can I solve it ?

#include <stdio.h>
int main(void) {
double x;
int i;

for (i = 0; i <= 20; i++) {
printf("x=%6.3f \n", x = 0.05 * i);
}
return 0;
}

Note the corrections to main and #include.
 
R

Richard Bos

[ Please don't top-post. ]
OK thanks but I hope that trere is an other more scientific way !

There isn't. The problem is the inherent inexactitude of floating-point
numbers, and there's nothing much you can do about that. As the FAQ (the
section on FP is at <http://c-faq.com/fp/index.html>) explains, checking
FP numbers exactly is rarely if ever a good idea, and you're usually
better off allowing for a certain error.

Richard
 
B

Barry Schwarz

[ Please don't top-post. ]
OK thanks but I hope that trere is an other more scientific way !

There isn't. The problem is the inherent inexactitude of floating-point
numbers, and there's nothing much you can do about that. As the FAQ (the
section on FP is at <http://c-faq.com/fp/index.html>) explains, checking
FP numbers exactly is rarely if ever a good idea, and you're usually
better off allowing for a certain error.

There are systems that support decimal floating point. I think there
is even an IEEE standard for it. While it doesn't change the nature
of the problem, it does change its appearance sufficiently to satisfy
people who think strictly in decimal. (If the OP's system used this,
it is unlikely he would ever have posted the question. Of course, he
would be confused as hell when it didn't work after being ported to a
binary system.)
 
S

soscpd

Hello Nikos, List

My 2 cents.

for (x=0.0;x<=1;x=x+0.05)
{
printf("x=%6.3f \n",x);
} /*
/str/dev/tmp/trash_it_out_00173.c
*/

/**/
#include <stdlib.h>
#include <stdio.h>

/**/
int main(void)
{
double x;
for (x=0.0;x<=100;x=x+5)
{
printf("x=%6.3f \n",x/100);
}
return EXIT_SUCCESS;
}

/*eof*/

Rafael
 
R

rahul

Of course, decimal arithmetic contains just as many surprises as floating
point.  Multiply two small quantities and get an itty-bitty one that gets
truncated.  Multiply this tiny thing which has lost all of its precision by
a huge thing and get a catastrophically wrong answer.  But at least it will
look nice.
Can you be specific about your surprises? IMO decimal arithmetic
models the way we think about numbers. Whereas floating poing does
some very weird things(viz. 0.1 + 0.2 != 0.3).
 
C

CBFalconer

rahul said:
Can you be specific about your surprises? IMO decimal arithmetic
models the way we think about numbers. Whereas floating poing does
some very weird things(viz. 0.1 + 0.2 != 0.3).

Well, try such things as (1/3) * 3. You can substitute any prime
not a factor of the base for 3. Then think about countability.
Integers are countable. Reals are not.

Countability simply means put in one to one correspondence with the
integers.
 
D

Dik T. Winter

> If you have a decimal value with format DECIMAL(15,2) and perform the
> following operation:
>
> 0.25 * 0.25 = .06

You are assuming fixed point decimal...
> On the other hand, decimal values do have the very pleasant property of
> adding to the same value when you sum then forwards and backwards, whereas
> binary floating point does not have this property.

Wrong if you consider floating point decimal. Also wrong if you consider
fixed point decimal and fixed point binary. And it is not even true in
fixed point. In one direction it is possible to have an intermediate
overflow that does not occur in the other direction.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top