On 8/25/15 11:56 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
On Tuesday, 25 August 2015 at 14:54:41 UTC, Steven Schveighoffer wrote:
As bachmeier says, it's not something that's easy to get right.
Are you sure you follow IEEE 754 recommendations? Floating point
arithmetics should be reproducible according to the chosen rounding mode.
https://en.wikipedia.org/wiki/IEEE_floating_point#Reproducibility
«The reproducibility clause recommends that language standards should
provide a means to write reproducible programs (i.e., programs that will
produce the same result in all implementations of a language), and
describes what needs to be done to achieve reproducible results.»
I'm not an expert on floating point, but I have written code that uses
it, and I have gotten it very wrong because I didn't take into account
the floating point error (worst was causing an infinite loop in a corner
case).
I'll note that D does exactly what C does in the case where you are
using 80-bit floating point numbers.
There is definitely an issue with the fact that storing it as a double
causes a change in the behavior, and that D doesn't treat expressions
that are typed as doubles, as doubles.
I see an issue with this:
double x = 1.2;
auto y = x * 10.0; // typed as double
writefln("%s %s", cast(ulong)y, cast(ulong)(x * 10.0)); // 12 11
IMO, these two operations should be the same. If the result of an
expression is detected to be double, then it should behave like one. You
can't have the calculation done in 80-bit mode, and then magically throw
away the rounding to get to 64-bit mode.
I think Marcio has a point that this is both surprising and troublesome.
But I think this is an anecdotal instance of a toy example. I'd expect
real code to use adjustments when truncating to avoid the FP error (this
obviously isn't his real code).
-Steve
