[Issue 11320] std.math.fmod, round, trunc are not yet pure

Jan 24, 2017

Ryan

Oct 14, 2018

Simon Naarmann

Oct 14, 2018

Oct 26, 2018

Oct 26, 2018

Nov 12, 2018

Dec 17, 2022

https://issues.dlang.org/show_bug.cgi?id=11320 Ryan <clumsycodemonkey@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clumsycodemonkey@gmail.com --- Comment #1 from Ryan <clumsycodemonkey@gmail.com> --- I can confirm this is still an issue in 2.071.2. --

https://issues.dlang.org/show_bug.cgi?id=11320 Simon Naarmann <eiderdaus@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eiderdaus@gmail.com --- Comment #2 from Simon Naarmann <eiderdaus@gmail.com> --- This issue is still in 2.082.0. Are there technical problems (floating representation etc.) that require impurity? Otherwise, I'll make a PR that adds the pure keyword. --

October 26, 2018

[Issue 11320] std.math.fmod, round, trunc are not yet pure

Posted by Simon Naarmann

Permalink

Simon Naarmann

Permalink

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

--- Comment #3 from Simon Naarmann <eiderdaus@gmail.com> ---
I see no problems to making fmod() pure.

But with round(), here's the Phobos code:

    auto round(real x) @trusted nothrow @nogc
    {
        version (CRuntime_Microsoft)
        {
            auto old = FloatingPointControl.getControlState();
            FloatingPointControl.setControlState(
                (old & (-1 - FloatingPointControl.roundingMask))
                | FloatingPointControl.roundToZero
            );
            x = rint((x >= 0) ? x + 0.5 : x - 0.5);
            FloatingPointControl.setControlState(old);
            return x;
        }
        else
            return core.stdc.math.roundl(x);
    }

Can the CRuntime_Microsoft version ever be pure? It backs up global state of the CPU's floating point processing, then restores it:

    static void setControlState(ControlState newState) @trusted
    {
        version (InlineAsm_X86_Any)
        {
            asm nothrow @nogc
            {
                fclex;
                fldcw newState;
            }
            // Also update MXCSR, SSE's control register.
            // ...
                asm nothrow @nogc { ldmxcsr mxcsr; }
        // ...

How should this be handled w.r.t. purity? I haven't looked at all into how such CPU state behaves with multithreaded code. For now, I'd have to leave round() as impure across all platforms.

--

https://issues.dlang.org/show_bug.cgi?id=11320 --- Comment #4 from Simon Naarmann <eiderdaus@gmail.com> --- D language spec, Pure Functions: https://dlang.org/spec/function.html#pure-functions In Point 8, it says: As a concession to practicality, a pure function can also: * read and write the floating point exception flags * read and write the floating point mode flags, as long as those flags are restored to their initial state upon function entry That's exactly what happens in round(), but through indirection. The compiler will not know that setControlState will be called a second time, and the compiler will not know that setControlState enjoys the special concession of the spec (it looks like any other impure function to the compiler). --

https://issues.dlang.org/show_bug.cgi?id=11320 Simon Naarmann <eiderdaus@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |All Assignee|eiderdaus@gmail.com |nobody@puremagic.com OS|Windows |All --- Comment #5 from Simon Naarmann <eiderdaus@gmail.com> --- Sorry, I lack the time these weeks. I've unassigned myself. Here are my ideas: - Refactor setControlState into a string mixin (seems best w.r.t. spec?) - Refactor setControlState into standalone pure function (weird because it's impure) - Cast round() to pure inside Phobos even though we call setCountrolState (feels like a bad idea) --

https://issues.dlang.org/show_bug.cgi?id=11320 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 --

Forums