On Tue, Mar 06, 2018 at 06:05:59PM +0000, jmh530 via Digitalmars-d-learn wrote:
> On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote:
> > [snip]
> > 
> > I'm not advocating for getting *rid* of 80-bit float support, but only to make it *optional* rather than the default, as currently done in std.math.
[...]
> Aren't there two issues: 1) std.math functions that cast to real to perform calculations, 2) the compiler sometimes converts things to real in the background when people don't want it to.
> 
> Number 1 seems straightforward to fix. Introduce new versions of the std.math functions for float/double and the user can cast to real if the additional accuracy is necessary.

The fix itself may be straightforward, but how to do it without breaking tons of existing code and provoking user backlash is the tricky part.


> Number 2 would require a compiler switch, I imagine.

It may not always be the compiler's fault. In the case of x87, it's the hardware itself that internally promotes to 80-bit and truncates later. IIRC, the original intent was that user code would only deal with 64-bit, and the 80-bit stuff would only happen inside the x87 (C, for example, does not provide direct access to this type, except via vendor extensions). However, due to the necessity to be able to save intermediate computational states, there are instructions that can load/extract 80-bit intermediate values to/from the x87, and eventually people ended up just using these instructions for working with the 80-bit type directly.  You can suppress the compiler from issuing these instructions, but 64-bit doubles may still be internally converted by the hardware to 80-bit intermediate values during computation.

But I suppose you could force the compiler to use SSE instructions for double operations instead of x87, then it would bypass the 80-bit intermediate values completely.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater learning.

On Tuesday, 6 March 2018 at 18:41:15 UTC, H. S. Teoh wrote:
>
> The fix itself may be straightforward, but how to do it without breaking tons of existing code and provoking user backlash is the tricky part.
> [snip]

Ah, I see what you're saying. People may be depending on the extra accuracy for these functions.

Would just require something like

double sin(double x) @safe pure nothrow @nogc
{
    version (FP_Math) {
        ///double sin implementation
    } else {
        return sin(cast(real) x);
    }
}