@SergioTulentsev: How do you figure this is a duplicate of that question? In `86.26.to_d`, the `86.26` ought to be converted to binary floating-point (as a literal in source code) and then converted to decimal (by the `to_d` operation). When this decimal value is compared with the `86.26` on the right, that `86.26` is implicitly converted to decimal. Regardless of floating-point issues, the same result should be obtained, since the same operations have been performed. However, I may not understand Ruby semantics—are the operations different than I have described?
– Eric PostpischilJan 15 '19 at 11:02
@SergioTulentsev: Some other Stack Overflow answers indicate there are [bugs in older implementations of `to_d`](https://stackoverflow.com/a/3003750/298225) that cause this behavior. Alternately, if that is not the cause, the question you gave as the original does not explain the Ruby semantics, which are necessary to understand how any floating-point behaviors apply, so this is not a duplicate.
– Eric PostpischilJan 15 '19 at 11:03
if I'm reading the source code correctly, `BigDecimalCmp` converts both self and the operand to rational numbers and compares those. `86.25.to_d.to_r` and `85.25.to_r` give the same result. Not so in the other case...
– Sergio TulentsevJan 15 '19 at 12:15
@SergioTulentsev: Thanks. Where does the difference arise? I would expect the literal `86.26` to produce the value 86.2600000000000051159076974727213382720947265625. Then does `86.26.to_d` produce that exact value in decimal or something else? And does `86.26.to_d.to_r` produce that same value as a rational or something else? And, finally, does `86.26.to_r` produce the same value or something else? One of the three must produce a different value, yes? That would be the answer to OP’s question.
– Eric PostpischilJan 15 '19 at 13:21