Thread: array confusions

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

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

QuantumPete

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

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

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

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

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