Floating point rounding modes: we should restrict them slightly
Don
nospam at nospam.com
Mon Sep 14 00:40:35 PDT 2009
Stewart Gordon wrote:
> Don wrote:
> <snip>
>>> Floating point settings are just another case of the same thing,
>>> except that currently violations in relation to the former are allowed.
>>
>> There's a fundamental difference between them: the floating point
>> settings are a hardware feature and it is IMPOSSIBLE to avoid them.
>
> Actually, you _can_ avoid changing the floating point settings in the
> course of an average program. But still....
The hardware dependency is still there, in every function which uses
floating point. And the compiler must assume that dependency.
>
>> You can choose not to use locale settings. Or, you can pass them as a
>> parameter, which doesn't work for floating point settings.
>
> As long as it's the built-in arithmetic operators you're concerned
> about.
Of course. There's nothing else to floating point, other than the
built-in operators. And this is the problem with unconstrained rounding
modes: they influence EVERYTHING.
>But that said, wrapping every arithmetic operation in a function
> to purify it of dependence on floating point settings wouldn't be ideal.
It's worse than that. Every function which might call a function which
might use floating point would have to pass the parameter. It doesn't work.
>> Please do not get sidetracked on pure functions, it is orthogonal to
>> this issue.
>
> I'm not sure about this. ISTM arithmetic operators are essentially pure
> functions, and so the compiler may treat them as such.
No, they always depend on the FP settings, and assuming they are pure
functions is not permitted in C, C++, or D. C allows the rounding mode
to change at any time.
This proposal:
Rounding mode changes must only affect callees, not callers.
The pure function memoisation issue:
Certain functions may be marked as 'pure', even though they use floating
point (and are therefore dependent on the FP state). The compiler must
be able to prevent memoisation of those functions in cases where the
rounding mode may have changed. (Or, equivalently, the memoisation must
include the FP state).
I've provided very simple solutions for both of these. I'm getting
pretty irritated that people are acting as though these are difficult
problems and trying to come up with convoluted solutions. Impose minimal
semantics and it becomes trivial.
More information about the Digitalmars-d
mailing list