Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/17/2016 11:08 AM, Timon Gehr wrote:
> Right. Hence, the 80-bit CTFE results have to be converted to the final
> precision at some point in order to commence the runtime computation. This means
> that additional rounding happens, which was not present in the original program.
> The additional total roundoff error this introduces can exceed the roundoff
> error you would have suffered by using the lower precision in the first place,
> sometimes completely defeating precision-enhancing improvements to an algorithm.

I'd like to see an example of double rounding "completely defeating" an 
algorithm, and why an unusual case of producing a slightly worse answer trumps 
the usual case of producing better answers.


> There are other reasons why I think that this kind of implementation-defined
> behaviour is a terribly bad idea, eg.:
>
> - it breaks common assumptions about code, especially how it behaves under
> seemingly innocuous refactorings, or with a different set of compiler flags.

As pointed out, this already happens with just about every language. It happens 
with all C/C++ compilers I'm aware of. It happens as the default behavior of the 
x86. And as pointed out, refactoring (x+y)+z to x+(y+z) often produces different 
results, and surprises a lot of people.


> - 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.

In fact, the results would be MORE portable than with C/C++, because the FP 
behavior is completely implementation defined, and compilers take advantage of that.