Always false float comparisons

[H. S. Teoh via Digitalmars-d]

On Tue, May 17, 2016 at 02:07:21PM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/17/2016 11:08 AM, Timon Gehr wrote:
[...]
> >- it breaks reproducibility, which is sometimes more important that
> >being close to the infinite precision result (which you cannot
> >guarantee with any finite floating point type anyway).  (E.g. in a
> >game, it is enough if the result seems plausible, but it should be
> >the same for everyone. For some scientific experiments, the ideal
> >case is to have 100% reproducibility of the computation, even if it
> >is horribly wrong, such that other scientists can easily uncover and
> >diagnose the problem, for example.)
> 
> Nobody is proposing a D feature that does not produce reproducible
> results with the same program on the same inputs. This complaint is a
> strawman, as I've pointed out multiple times.

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.

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.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL