Always false float comparisons

[Joakim via Digitalmars-d]

On Wednesday, 18 May 2016 at 17:10:25 UTC, Timon Gehr wrote:
> It's not just slightly worse, it can cut the number of useful 
> bits in half or more! It is not unusual, I have actually run 
> into those problems in the past, and it can break an algorithm 
> that is in Phobos today!

I wouldn't call that broken.  Looking at the hex output by 
replacing %f with %A in writefln, it appears the only differences 
in all those results is the last byte in the significand.  As 
Don's talk pointed out, all floating-point calculations will see 
loss of precision starting there.

In this case, not increasing precision gets the more accurate 
result, but other examples could be constructed that _heavily_ 
favor increasing precision.  In fact, almost any real-world, 
non-toy calculation would favor it.

In any case, nobody should depend on the precision out that far 
being accurate or "reliable."