quote:

---

Original post by johnb

Original post by TerranFury
In other words: There is nothing you can do with a float that you can''t do with a double.

---

You can''t write fast games: if we replaced all our float code with double code the game would probably drop from 60 to well under 30 fps.

Floats are accurate to better than 1 part in a million, i.e. errors are less than 1mm per km, I can''t think of any gaming appilcation for better precision than this. For comparison in science experiements are usually accurate to no more than 1 part in a thousand, and are often a lot less accurate.

For single calculations, regular floats would be fine if they are precise enough, however the original poster complained of losing accuracy over time. as in, you lose a little accuracy per calc over 100000 calcs, it adds up. so, use a double!

Brief overview of IEEE 754 floating point data types:

S is sign (1 bit)
E is exponent (8/11 bits)
M is mantissa (23/52 bits)

- 32 bits (aka float): ((-1)^S)*(2^(E-127))*1,M

- 64 bits (aka double): ((-1)^S)*(2^(E-1023))*1,M

...



[edited by - bloodscourge on March 28, 2002 12:34:51 PM]

You have two main options. One is to adjust the value periodically. Whether that is actually an option depends upon how accurately you can predict the error. With our calendar we can say we are going to be off by about a day every four years. We also know that if you make an adjustment every four years by a whole day that after 400 years we would be off by 3 days. We know if we make adjustments for that error then after several thousand years we will be off by day and need yet another adjustment.

The other option is to re-establish the number. Generally you iterate a calculation for performance. It takes a lot of work to calculate what the value should be, but relatively easy to say how it should have changed from the previous value. So you update the value for awhile and then recalculate it. If the error grows too fast then you have to break the calculation down. As an example perhaps you are using some ratio and error is coming mainly from the division. So instead you carry and update the numerator and denominator. The same error still occurs each time you do the division, but you are not compounding the error.

Floats and doubles have a fixed number of significant digits, and round anything past them.

If presicion is more important than speed (and I assume that it is for you) then look into the GNU Multiple Precision Library: http://swox.com/gmp/
It should offer the presicion you want

Karg