Proposal: fixing the 'pure' floating point problem.

[Don]

Philip Miess 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.
> 
> 
> Walter,
>     I had a simpler idea.
> What about a default rounding mode parameter on pure functions that care 
> about the rounding mode.
> 
> like this
> 
> pure int sqrt(int x, invariant roundingMode round = default)
> {
>     return x*x;
> }
> 
> No change to D is necessary to use this.
> If you wanted to make it a little easier you could
> provide a standard rounding mode class that gets the current rounding mode.
> now if don't want to use the default rounding mode you pass the rounding 
> Mode your using as a parameter.
> The function can be cached since it's output only depends on its input.
> 
> In summary, if your pure function depends on the rounding mode that 
> should be a parameter of your function.
> What do you think, will that work?
> 
> Phil
> 

That's actually a LOT more complicated than my suggestion. Also, it's 
not how the rounding modes work.

Aargh. It seems that people don't understand that my solution DOES fix 
the problem, and is trivial to implement (< 10 lines of code in the DMD 
source, one line change in a couple of standard library modules and 
THAT'S ALL). Nobody has come up with any problems with it.

Especially, I don't think Walter understands my proposal yet.

But thanks for replying to the thread, I think it's an important one to 
get fixed.