On 2012-03-09 02:32, Roman Haefeli wrote:
On Thu, 2012-03-08 at 18:03 -0500, Mathieu Bouchard wrote:
Le 2012-03-08 à 11:47:00, Jonathan Wilkes a écrit :
From: Roman Haefeli<[email protected]>
That's a good example of the implications inherent in floats. What you
call a work-around is actually the correct solution. When counting, make
sure you count with something that can precisely represented by floats,
otherwise the error will grow with each iteration. Integers up to
1.6*10^7 meet that criterion.
Is this still an issue when float precision is 64-bit?
in float32 you have 24 significant bits.
in float64 you have 53 significant bits.
This means that the limit is pushed back from 16777216 to 9007199254740992
instead.
But 0.1 still cannot be represented exactly by float64, can it?
For any floatX unless X is infinity the number of floats that are not
exactly represented is always infinite.
Martin
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
