Perl: the Markov chain saw  
PerlMonks 
Re: Calculation discrepancy between Perl versionsby sundialsvc4 (Abbot) 
on Oct 06, 2010 at 17:50 UTC ( #863841=note: print w/ replies, xml )  Need Help?? 
The adage that I heard was: “Floating point numbers like piles of dirt on a beach. Every time you pick one up and move it around, you lose a little dirt and you pick up a little sand.” Every implementation ought to produce the same answer, within the useful number of significantdigits, for most calculations. But, the more calculations you do (and depending on exactly how you do it), the more the results will “drift” toward utter nonsense. And I truly think that you should expect this from any binary floatingpoint implementation. There are two classic ways that applications (such as, accounting applications in particular) counter this:
Even so, errors can accumulate. This can be further addressed by algorithms such as “banker’s rounding.” There is, of course, the (probably apocryphal) tale of an intrepid computerprogrammer who found a way to scoop all of those minuscule roundingerrors into his own bank account... Floatbinary can never be a “pure” data representation. It is wellunderstood that the fraction 1/3 cannot be precisely expressed as a decimal number. Similar artifacts occur for other fractions in other bases, and, so they tell me, for base2 floats, one of those unfortunate numbers is 1/10. (“So I have been told.” I don’t have enough geekknowledge to actually know for sure...)
In Section
Seekers of Perl Wisdom

