Always false float comparisons

[jmh530 via Digitalmars-d]

On Monday, 16 May 2016 at 14:32:55 UTC, Andrei Alexandrescu wrote:
>
> Let's do what everybody did to x87: continue supporting, but 
> slowly and surely drive it to obsolescence.
>
> That's the right way.

This is a long thread that has covered a lot of ground. There has 
been a lot of argument, but few concrete take-a-ways (this was 
one, why I'm quoting it).

As far as I see it, the main topics have been:

1) Change in precision during comparisons (the original)
2) Change in precision to real during intermediate floating point 
calculations
3) Floating point precision in CTFE

On #1, there was discussion initially about compiler warnings as 
a solution. I have not seen any concrete recommendations.

Personally, I am not a fan of implicit conversions. It's one more 
set of rules I need to remember. I would prefer a compile-time 
error with a recommendation to explicitly cast to whatever is the 
best precision. It may even make sense for the error to also 
recommend approxEqual.

On #2, I don't see any clear agreement on anything. Walter 
emphasized the importance of precision, while others emphasized 
determinism and speed.

As someone who sometimes does matrix inversions and gets 
eigenvalues, I'm sympathetic to Walter's points about precision. 
For some applications, additional precision is essential. 
However, others clearly want the option to disable this behavior.

Walter stressed Java's difficulty in resolving the issue. What 
about their solution? They have strictfp, which allows exactly 
the behavior people like Manu seem to want. In D, you could make 
it an attribute. The benefit of adding the new annotation is that 
no code would get broken. You could write

@strictfp:

at the top of a file instead of a compiler flag. You could also 
add a @defaultfp (or !strictfp or @strictfp(false)) as its 
complement.

I'm not sure whether it should be applied recursively. Perhaps? A 
recursive approach can be difficult. However, a non-recursive 
approach would be limited in some ways. You'd have to do some 
work on std.math to get it working.

On #3, resolving #2 might address some of this. Regardless, this 
topic seems to be the least fully formed. Improved CTFE seems 
universally regarded as a positive.