https://issues.dlang.org/show_bug.cgi?id=9937

--- Comment #20 from yebblies <yebblies@gmail.com> ---
The problem in issue 13474 is a case where extra precision causes tests to fail.

--

https://issues.dlang.org/show_bug.cgi?id=9937

Илья Ярошенко <ilyayaroshenko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilyayaroshenko@gmail.com

--- Comment #21 from Илья Ярошенко <ilyayaroshenko@gmail.com> ---
(In reply to Walter Bright from comment #1)
> I'm going to disagree.
> 
> In D, any floating point algorithm that relies on a maximum precision is broken. The compiler and runtime is allowed to do all such calculations at as high a precision as they want to - the types only specify a minimum precision, not a maximum.
> 
> This is unlike C, which requires a maximum precision upon assignment.

So D is not system language?
How this http://cage.ugent.be/~klein/papers/floating-point.pdf
and
msum from http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/393090
 can be implemented in D for float and double?

For my implementation see PR
https://github.com/D-Programming-Language/phobos/pull/2513
This PR works well with GDC, LDC2 and DMD64. But not with DMD32.

--

https://issues.dlang.org/show_bug.cgi?id=9937

--- Comment #22 from yebblies <yebblies@gmail.com> ---
Just for reference, the exact cause of the trouble for the specific case in issue 13474 is that floating point expressions can be evaluated with different precision within the same code.

eg this assertion could fail:
double a;
double b;
double c;
assert(a + b - c == a + b - c);

Because it could be evaluated as
(a + b - c) == cast(double)(cast(real)a + cast(real)b - cast(real)c)

This is a little disturbing.

--

https://issues.dlang.org/show_bug.cgi?id=9937

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1 & D2                     |D2

--

https://issues.dlang.org/show_bug.cgi?id=9937

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #23 from Martin Nowak <code@dawg.eu> ---
The real problem is that dmd (as only compiler) ignores `cast(float)myReal`
when the float is converted to a higher precision after that.
This optimization is semantically incorrect b/c rounding down can have side
effects (setting exception flags). It's also unexpected b/c C (and gdc/ldc)
correctly perform the rounding.

Also see https://github.com/dlang/druntime/pull/1621#issuecomment-250426515

--

https://issues.dlang.org/show_bug.cgi?id=9937

--- Comment #24 from Martin Nowak <code@dawg.eu> ---
Also see the discussion in issue 13474 and "The semantics of float, double, and real" at http://dlang.org/d-floating-point.html, which gives some arguments why dmd uses -ffast-math behavior by default behavior.

I think the spec argumentation is a bit weak (also see https://issues.dlang.org/show_bug.cgi?id=13474#c21).

If someone asks to round down (cast(float) or assignment to float) it seems
sensible to do it.
If you're writing performance sensitive numeric code you will avoid to mix
precisions.
DMD is the only C/D/C++ compiler skipping such those roundings by default (w/o
a -ffast-math switch).

In any case we need to align the default behavior of dmd/gdc/ldc.

--

https://issues.dlang.org/show_bug.cgi?id=9937

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #25 from Iain Buclaw <ibuclaw@gdcproject.org> ---
toPrec intrinsic implemented in compiler, and functions added to druntime.

https://github.com/dlang/dmd/pull/10654 https://github.com/dlang/druntime/pull/2864

--

https://issues.dlang.org/show_bug.cgi?id=9937

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #26 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ibuclaw created dlang/dmd pull request #10686 "Fix Issue 9937: CTFE floats don't overflow correctly" fixing this issue:

- Fix Issue 9937: CTFE floats don't overflow correctly

  Adjusts original test to include new toPrec intrinsic

https://github.com/dlang/dmd/pull/10686

--

https://issues.dlang.org/show_bug.cgi?id=9937

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #10686 "Fix Issue 9937: CTFE floats don't overflow correctly" was merged into master:

- ea47332fb00829eb5d234daa9f2c618d544a596b by Iain Buclaw:
  Fix Issue 9937: CTFE floats don't overflow correctly

  Adjusts original test to include new toPrec intrinsic

https://github.com/dlang/dmd/pull/10686

--

https://issues.dlang.org/show_bug.cgi?id=9937

--- Comment #28 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #11055 "[dmd-cxx] Fix Issue 9937: CTFE floats don't overflow correctly" was merged into dmd-cxx:

- 843a7fe13a18fae66bcf2af45b0a9ef7b241da36 by Iain Buclaw:
  [dmd-cxx] Fix Issue 9937: CTFE floats don't overflow correctly

  Adjusts original test to include new toPrec intrinsic

https://github.com/dlang/dmd/pull/11055

--