That is not the issue here -- after all, BigDecimal does precise

arithmetic, but only with rational numbers. The issue is rather that

IEEE 754 does an inadequate job of representing arbitrary rational

numbers, and the small errors are accumulated and magnified in

calculations.

I'd like to emphasize the fact that it is a very specific

representation problem that most often leads to a thread such

as this. That problem is a misunderstanding about the nature

of converting between a base 10 literal and a base 2 internal

value.

Many people don't realize that floating point literals written

in base 10 (such as 123.6) may not have an exact finite

representation when converted to base 2 and similarly a finite

base 2 floating point value may not have a finite representation

in base 10.

In the original post the floating point subtraction in the

expression (123.6 - 123.0) is handled just fine. The problem

is that 123.6 can't be represented exactly as a base 2 floating

point value so the subtraction that actually gets done is

123.599999999999994315658113919198513031005859375 - 123.0

and the result

0.599999999999994315658113919198513031005859375

is rounded via Ruby's Float#to_s method to

0.599999999999994

Gary Wright