Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/17/2016 5:22 PM, H. S. Teoh via Digitalmars-d wrote:
> Wasn't Manu's original complaint that, given a particular piece of FP
> code that uses floats, evaluating that code at compile-time may produce
> different results than evaluating it at runtime, because (as you're
> proposing) the compiler will use higher precision than specified for
> intermediate results?  Of course, the compile-time answer is arguably
> "more correct" because it has less roundoff error, but the point here is
> not how accurate that answer is, but that it *doesn't match the runtime
> results*. This mismatch, from what I understand, is what causes the
> graphical glitches that Manu was referring to.

Except this happens with C/C++ too, and in fact Manu wasn't using D.

> According to your prescription, then, the runtime code should be "fixed"
> to use higher precision, so that it will also produce the same, "more
> correct" answer.  But unfortunately, that's not workable because of the
> performance implications. At the end of the day, nobody cares whether a
> game draws a polygon with the most precise coordinates, what people *do*
> care is that there's a mismatch between the "more correct" and "less
> correct" rendering of the polygon (produced, respectively, from CTFE and
> from runtime) that causes a visually noticeable glitch. It *looks*
> wrong, no matter how much you may argue that it's "more correct". You
> are probably right scientifically, but in a game, people are concerned
> about what they see, not whether polygon coordinates have less roundoff
> error at CTFE vs. at runtime.

That wasn't my prescription. My prescription was either changing the algorithm 
so it was not sensitive to exact bits-in-last-place, or to use roundToFloat() 
and roundToDouble() functions.