1. ## array confusions

Can Somebody explain this?????????????????

program outputs :

4
1
Press Any Key...........

Code:
```double d_array[10] = {3.4, 12.8, 9.5, 2.0, 1.7, 3.8};
char letters[26];
int i;
double j;
int k;
int l;

for(i=0; i<1; ++i)
{
k=d_array[i];

j=d_array[i]-k;

j*=10;
cout<<j<<endl;
l=j;

cout<<(int)j%2<<endl;

if((int)j%2==0)
cout<<d_array[i]<<endl;

}```

Heres the question, why does the number when coverted from double to int result in 1?????
and not 4???????

2. Becuase floating point (e.g. double) is not exact - in this case, 3.4 - 3 * 10 makes 3.999999999999. This rounded to int makes 3. You need to add a small offset. I changed your code to:
Code:
```	j*=10;
j+=0.0001;
cout << (int)j<<endl;```
It now shows 3.4 as "even" (although by my definition, as explained in the previous post, floating point numbers are not even and odd - only integers can be).

And perhaps it would be better to multiply by 10 first, then make it into an integer (you will still have to do some rounding operation).

--
Mats

3. thx for that swift and very precise reply, i did although change the program around myself

Code:
```for(i=0; i<6; ++i)
{
y=d_array[i]-(int)d_array[i];
y*=10;
int k=y+0.5;
if(k%2==0)
{
cout<<d_array[i]<<endl<<endl;
cout<<"Number Is Even!!!!"<<endl<<endl;
continue;
}
else
{```
to this but its the same effect as your suggestion , thx again definately cleared things up

4. First rule for using floats and doubles in C: Don't!

QuantumPete

5. hehe il take that into consideration thanks!!!

6. Originally Posted by QuantumPete
First rule for using floats and doubles in C: Don't!

QuantumPete
This is of course not specific to C - it's the same in Fortran, C++, Pascal or whatever other language you may consider - unless it's not using the standard floating point formats, it will not overcome the "not precise" limitation.

--
Mats

7. Originally Posted by matsp
This is of course not specific to C -
Sorry, forgot I was posting in the C++ forum :P
I'm surprised actually that there isn't a standard class in C++ that does accurate floating point operations. Does Boost have something like that?

QuantumPete

8. Originally Posted by QuantumPete
Sorry, forgot I was posting in the C++ forum :P
I'm surprised actually that there isn't a standard class in C++ that does accurate floating point operations. Does Boost have something like that?

QuantumPete
But that would require an infinite number of bits. And the point here is that double is 8 bytes (in most architecturse), which is a reasonably small amount of bits - but it's still good enough for about 15 or more places of correct result. The problem comes when comparing precise values and/or converting to integer.

I'm sure there are bignum libraries (e.g. GMP) that support really large numbers of high precision - but they are STILL approximations.

Unless you can device another way to describe the numbers (for some things, you could of course use fraction representation, e.g. 0.7 described as 7/10).

This problem CAN NOT BE TRIVIALLY SOLVED for all problem settings with one solution.

--
Mats

9. Originally Posted by matsp
But that would require an infinite number of bits.
[...]
This problem CAN NOT BE TRIVIALLY SOLVED for all problem settings with one solution.
I meant "accurate" as in with more bits than a double has. Like you said, this is not something that can be easily solved, which lead to the first-rule-for-using-floats-and-doubles in the first place!
If you only need two d.p., use ints and convert for output.

QuantumPete

10. Originally Posted by QuantumPete
I meant "accurate" as in with more bits than a double has. Like you said, this is not something that can be easily solved, which lead to the first-rule-for-using-floats-and-doubles in the first place!
If you only need two d.p., use ints and convert for output.

QuantumPete
Sure, fixed point is one of many solutions to "don't use floating point". In the case of multiples of 0.1 (which 3.4 is), it's not helping to have more precision. Representing 0.1 in a binary form is just like representing 1/3 in a decimal form - it never ends. One solution to this problem is to use BCD floats, which use 4 bits to store 0-9. But it's noticeably less efficient both in the math itself and usage of space, so it's not use very often. Turbo Pascal 3.x had a BCD library for it's floating point, which I used for calculations of monetary amounts at one stage in the late 80's. In later versions of software related to this, I used big integers and representing pence, just re-formatting for output, like you explained.

--
Mats