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.
