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 significant-digits, 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 floating-point implementation.   There are two classic ways that applications (such as, accounting applications in particular) counter this:

• Binary-Coded Decimal (BCD):   The calculations truly are performed in decimal mode, using 4 bits per decimal integer.   (COBOL turned this into a science.)
• Scaled Integers:   The calculations are performed using integer arithmetic, and the result is understood to be “multiplied by (say...) 10,000,” giving you a fixed precision of (say...) 4 digits to the right of the decimal.   (Microsoft Access uses this strategy in their “Currency” data-type.)

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 computer-programmer who found a way to scoop all of those minuscule rounding-errors into his own bank account...

Float-binary can never be a “pure” data representation.   It is well-understood 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 base-2 floats, one of those unfortunate numbers is 1/10.   (“So I have been told.”   I don’t have enough geek-knowledge to actually know for sure...)