Don't you see 10 if you run the code ?
The key point to remember is that floating point arithmetic uses *approched*
values because it has to be a compromise between the range and precision
(for example values that are not a power of two have even no exact
representation).
You'll find tons of articles about that on the web but basically my
understanding is :
- floating points values are kept as an approched value
- they are displayed using less significant digits than stored (to increase
the precision and likely not confuse users with visible approximations).
This what the "r" format does. It shows the actual underlying value.
So in most cases those approximations are not visible.
In this particular case :
- 10/3 is stored as a value that multiplied by 3 (and possibly truncated for
user display will give back 10) because the representation of the result of
10/3 is not the same than 9.999 as you have some additional digits resulting
from the calculation that are not shown...
- If you take the visible value and multiple by 3 you won't have 10 but
9.999 etc...
- if you take the actual underlying value and multiply by 3 you'll have back
10 (perhaps 10.00000000005 and possible right digits are either not stored
or truncated for user display giving finally 10)
I'm not sure if this is really something you would like to fix (generally
one complain when the result is not mathematically correct).
If you want to guarantee the precision you could use the Decimal type
instead. If you want to have 9.999999 you'll have to truncate the value to a
fixed size explictely.
As a side note you generally compare floating point values by checking that
the absolute difference is less than a threshold to take into account those
possible approximations...
Hope it helps.
--
Patrice
"Peter Ramsebner" <pe*************@pr.ata écrit dans le message de groupe
de discussion :
ue**************@TK2MSFTNGP06.phx.gbl...
> Debug.Print(3.3333333333333335 * 3) ' Which is 10
it's not 10! It's 10,0000000005