Thread: float13

Originally Posted by esbo

Yes but the same happens with

6 0.6000000238 5 7 0.7000000477
7 0.6999999881 6 8 0.8000000119 <-----------
8 0.8000000119 7 9 0.9000000358

Or does it.
Explain why it does not happen here?

Like I said, that is an artifact of the printing of the numbers, not an effect of the actual value. Printing floating point values involve divide or multiply and subtraction - if we ignore the > 1 part of a floating point number:

Code:

float f = 0.6f;
int precision = 7;
while(f && precision > 0)
{
     int n = (int)10.0f * f;
     putchar(n + '0');
     f *= 10.0f;
     f -= (float)n;
     precision--;
}

Note I just typed that in, it may not be quite right - but the essence is that it involves some math operations. And since the floating point calculations are not precise, we can not rely on the value actually being PRECISE, particularly not when we get to the lower bits of the floating point value, where errors may have be introduced already from previous operations.

--
Mats

Originally Posted by esbo

Well I am not to sure what is happening really, probably not what I suspected, the only
person who knows is the one who wrote the compiler.

Actually, I bet that at least 5 million people on this planet understand it, including most of the people who've replied to you.

Originally Posted by esbo

Not true less than 400 people have viewed the tread

And of course not every computer literate person frequents this forum - of the people that I work with, I'm the ONLY ONE that frequently visits C programming forum - but I'm sure at least half of them understand this problem (so that makes about 30x me, which means that we should be around 12000 if the 400 people who viewed this thread understands it - I'm sure the proportion "sufficiently computer literate vs C programming forum members" is a fair bit higher than 1:30 - more like 1:10000 perhaps, which would put brewbuck's number around the right order of magnitude).

Some of the people I work with DO NOT understand the concept of inprecise floating point results, and it's not really important for their job to understand it. It may not be important to you either.

--
Mats

Originally Posted by esbo

Main problem as I see it is in the conversion to an int, which is a weird operation in the
first place, rather ill defined and vague, losing up to 0.99999 of value.

Yes, this is the root of the problem to a large extent, and there are (a few) languages that rounds instead of truncates. They have other problems with illogical results.

And converting to integer from a float is something that requires some care and attention if you want it to come up "right" [whatever that means - depends on the application and data range].

Basically the original problem is 'designed' to produce this fault.
A more sensible method of casting would be appropiate.
Computer should store number in the base it finds them
If you wanted imprecise storage maybe you should have to specify it?

That is exactly what float and double are - if you use them, the result is not precise, it's a (close) approximation. And in 99.99% of usage of floating point types, the inprecise result is perfectly fine, because it is not convered back and forth between integer and float - so the problem is not that apparent. However, this thread is a typical example of WHY care and attention should be used in this type of case.

We had someone a while back wonder why (simplified example):

Code:

float x = 1.4f;
..
if (x == 1.4)
..

the if-statement never got true... Because 1.4 is a double constant which requires infinite precision to describe it precisely, so it becomes 1.399999999996, and x is a float which has a value of 1.3999960000000 when converted to double - not exacly the same thing, which is == compares for. Adding a f to the 1.4 makes it a float value, and the comparison matches. A better solution would of course be to say:

Code:

const float epsilon = 0.000001f;
float x = 1.4f;
..
if (fabs(x - 1.4f) < epsilon)
..

(Of course, epsilon needs to be adjusted accordingly to the size of x and 1.4).

--
Mats

Originally Posted by esbo

Well if would not be impoortant to me in the real world because I would never have
written a piece of code like that in the first place. The code seems designed to
produce the problem.

Yes, I think that's a fair assesment of the code in question. However, problems can occur due the inprecise way floating point is, even if you don't use code like this.

I don't think most people would have understood the problem in it's entirity, yes most
would know that computers don't store numbers accurately, but that is only part of
the problem.
Would they know the number of bits used to store each number? I doubt many
would it is undefined guess work for a start, depends on the computer etc...
I doubt many are walking encyclopedia of IEEE regs either.
Alos I doubt many of them could convert numbers into binary in their heads and know
what the error was.
Sure some people like to sound like they know it all, but more often than not they don't,
I know that from experience.


Part of the key to the problem is the error in storing particular fractions

The number of bits doesn't make any difference - it may take a bit more iterations before it happens, but it will happen with the double precision numbers too, and they have more than twice as many bits. And IEEE has very little to do with it. Non-IEEE representations of floating point are equally afflicted.

And of course, converting numbers into binary is only necessary to EXPLAIN how it happens, not to understand the basic idea of what happens.

--
Mats

Originally Posted by esbo

I was concerned not just that the problem occured, but *when* it would occur.
It seems that is when the error, when negative, in a particular conversion into
decimal is greater than the error of converting 0.1 into decimal.
I doubt many people would know that 'off the top of their head'!!
(At least I would hope not!!)

I agree, it would be tough to know without further investigation exactly when the problem would occur. On the other hand, the important point is to do what you have suggested: understand, at least vaguely, the problem, and thus avoid writing such code in the first place.

Originally Posted by esbo

I knew one guy who had spend months trying to get payroll calculations right!! lol.
Kept him in a job I guess.

I guess so. But obviously, only until someone else starts working for that company, that is competent in the job [assuming of course the payroll calculations aren't VERY complicated - I'm sure that a large company with many different forms of pay and tax calculatins may actually require months of work to get the payroll right].

--
Mats