Floating numbers and precision
BlitzMax Forums/BlitzMax Beginners Area/Floating numbers and precision
| ||
| Hi, can somebody give me some advice? i have this small piece of code: SuperStrict Local w:Float = 0 Local n:Float = 1. Local inc:Float = 0.1 Local result:Float = n + inc Print result result:+inc Print result End What happens here is that float numbers doesnt appear to be very precise... the resulting printing gives 1.10000002 when it should be 1.10000000 1.20000005 when it should be 1.20000000 ¿why? Thanks in advance! |
| ||
| Because some numbers cannot be perfectly represented with only 32 bits of precision. I'm not going to give a complete treatise on how floating point numbers are represented bit-by-bit because you can research that on a hundred sites just by googling. Suffice it to say that even within the seven digit precision you can generally expect from floating point numbers there are too many combinations for all numbers to be perfectly represented. If you want greater precision, use doubles. If you want perfect precision, don't use floating point values at all. |
| ||
| Although when trying to apply percise mathematics, floating points can seem terrible, when used for many caculations the inpercision is actually not that significant in many cases. For example, in many of the experiments I conduct at university, if I can collect results accurate to even as few as 3 decimal places accurately, then I'm going to be very pleased (although of course it depends entirely upon what I'm measuring!) When dealing with formulas for things such as distance etc the fact that the number is only accurate to the 7th decimal place is hardly ever going to be of an consequence. When dealing with percise maths, stay away! |
| ||
| A floating point number is not the same thing as a REAL number - it cannot accurately represent all numbers. You only have 32 bits within which to specify enough detail to get close to a number. In some cases you get as close as needed but in other cases there either isn't enough decimal places, or the `spread` of numerical representation is not precice enough to represent the numbers you want precicely. You can move to trying to use Doubles, as Gabriel suggested, or otherwise you have to create some kind of `if this number is within a certain error tolerance range of this other number` function ie approximately equals. |
| ||
| Hey thanks four your help! Didnt knew that thing about floating point numbers so, i guess i´ll use doubles instead. :) thanks :D |
| ||
| I feel I should point out a double IS a floating point number, just one with twice the accuracy. |
| ||
| and far lower performance as float is handled natively by the CPU while double needs to be calculated in several steps. |
| ||
| Yah floats are faster than doubles. That said, I find that Longs are even slower than doubles which is susprising. You might try fixed point within an integer. You can't accurately/reliably represent any non-integer/non-whole numbers, you can only approximate. |
| ||
| and far lower performance as float is handled natively by the CPU while double needs to be calculated in several steps. The FPU does all calculations with 80-bit registers, doubles should be handled just as natively as floats. |
| ||
| ¿why? Becuase: What happens here is that float numbers doesnt appear to be very precise... Tada! and far lower performance as float is handled natively by the CPU while double needs to be calculated in several steps. Rubbish. Like Azathoth said, floating point numbers, regardless of single or double precision, are handled by the FPU (the CPU handles integer arithmetic) using 80-bit registers. There is no performance penalty for using one over the other. |
   |