Always false float comparisons

[Timon Gehr via Digitalmars-d]

On 16.05.2016 06:26, Walter Bright wrote:
>>
>> Incidentally, I made the mistake of mentioning this thread (due to my
>> astonishment that CTFE ignores float types)
>
> Float types are not selected because they are less accurate,

(AFAIK, accuracy is a property of a value given some additional context. 
Types have precision.)

> they are selected because they are smaller and faster.

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.

This might be counter-intuitive, but this is floating point. The 
precision should just stay the specified one during the entire 
computation (even if part of it is evaluated at compile-time).

The claim here is /not/ that lower precision throughout delivers more 
accurate results. The additional rounding is the problem.


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.

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