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