Proposal: fixing the 'pure' floating point problem.
Don
nospam at nospam.com
Sat Mar 14 01:43:14 PDT 2009
Don wrote:
> Walter Bright wrote:
>> Don wrote:
>>> That's true, but if you're in a floatingpoint module, and you call a
>>> non-floatingpoint module, it's your responsibility to make sure that
>>> the rounding mode is back to normal. You're saying that you don't
>>> care about the status flags. So it's your own fault if you get
>>> surprising results.
>>>
>>> The primary use for adjusting the rounding mode is for things like
>>> implementing interval arithmetic. Thus, it's only ever used for small
>>> functions.
>>
>> Perhaps we can go with something simpler. If you call a pure function,
>> then the modes must be set to their defaults.
>
> But then nothing in std.math can be pure.
My proposal is pretty simple -- I doubt we can come up with anything
simpler that's useful.
To clarify the effect of my proposal:
normal function calls floatingpoint function -- rounding mode respected,
sticky status flags can be ignored.
floatingpoint function calls floatingpoint function -- rounding mode
respected, sticky flags set correctly.
floatingpoint function calls normal function -- rounding mode may be
respected, or you may get default rounding instead (implementation
defined). Sticky flags may not be set in all cases, but none will be
cleared.
So, a floatingpoint function should not make any calls to normal
functions under circumstances in which it needs guaranteed rounding, or
where it relies on the sticky flags. I think that's a managable limitation.
The only other alternative I can see is to require that EVERY function
save the status flags and check the control register before caching any
pure function. Which seems a lot of complexity for the sake of a few
really obscure cases.
More information about the Digitalmars-d
mailing list