Beware of trying to use a float as an incrementer. index += 1.0 a 1000 times does not each 1000 :-)... at least much of the time it doesn''t. That is why no sane person would use it for keeping track of monetary values. Division rounding can add up rather quickly also. If your worried about speed, many times you can pull of with ints what your trying to pull off with a float, only a lot faster. Other pitfalls I have had with floats is that watch out for casts. I''ve spent 3 hours trying to figure out why an algorithm wouldn''t work only to figure out even though I was doing an operation to a double, I was dividing an int by and int first.


Basically I would stay away from anything float where you need absolute precision. The reason accuracy is such a problem is that a float is limited in percision (Yes I''m probably spelling it wrong). A float in x86 architecture is usually a 32 bit approximation of a decimal. If you divide 1/3 and then multiply by 3 again, you''ll most likely get a .9999999.... This is because even though you should be adding the same amount back, that .999 off to infinity was loss. Thus you go .9999999 out to however many decimal places a float is (I don''t feel like looking it up).


Floating points are great though for things that don''t have to be accurate just really close. Such is the case with the real world. There is no way to accurately tell what the real world does, so why should it matter if you lose a little accuracy. BTW, what you read about floats is true if you cause the float to overflow.

Floating point is interesting. There are very convincing reasons to use floating point and to avoid it.


Pros:
Very easy to represent virtually any real number (not precise)
Floating point hardware has been getting much faster

Cons:
Different floating point hardware will produdce *slightly* different results. This can be a problem for network games.

Some floating point hardware is only barely complient with the floating point specifications. Underflow (the smallest floats) can cause operations to take 100 times as long as normal.

[edited by - pTymN on May 18, 2004 11:34:50 AM]

In general most of the problems of floating point numbers can be understood by understanding that a floating point number only has so many significant digits. For C/C++, a float (32-bits) has roughly 6 digits of accuracy. That means that 0.100001 is fine, because 100001 is six digits worth. However, if you tried to store 0.10000001 in a float, you''d lose that 1 on the end. Actually, you wouldn''t simply lose it, but after enough digits, insignificant digits will be "random", since floating point is in binary, but you''re trying to view it in decimal. Beyond 6 digits, things simply get quite inaccurate.

Thus, to explain a few of the common things you mentioned avoiding, in light of this information:

Subtracting similar floats:

If you have two large floats, 123456789.0 and 123456889.0, you have to realize that they''re probably already not as accurate as you think, since all that you can be guaranteed of are the first 6 digits. Thus, even though the seventh digit should be different, it''s hard to tell what will result if you subtract the two.

Using large floats:

Using large floats isn''t a problem by itself. The problem is when you use large floats, but still want accuracy at the one''s, ten''s or hundred''s level. If you have a number like 1.0e20, then you can''t expect to be accurate at the one''s or ten''s level. But this applies to small numbers, too. If you have 1.0e-20, then this is a small number, but don''t expect to have accuracy beyond 1.0e-26 or so.

Adding small float to large float:

If you have two numbers: 10000.0 and 0.00001, and you add them, you should get:

10000.00000
0.00001
---------------
10000.00001

But you''ll notice that this is plenty more than 6 digits. That last 1 is gonna be lost in a bunch of inaccuracy.


double (64-bit) has roughly 15 digits of accuracy, so it''s a lot better than float, but it still has the same problems; it just takes more to get the problems to occur.