Proposal: fixing the 'pure' floating point problem.

[Philip Miess]

Don wrote:
> 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.


Don,
	here is an improved version of my suggestion

import std.c.fenv;
import std.math;

pure long myround(real x, int round = fegetround() )
{
	
  	return lrint(x);
}

int main(char[][] args)
{
	long result;
	result = myround(2.6);
	//result is now 3

	fsetround(FE_DOWNWARD);
	result = myround(2.6);
	//result is now 2
}

I think that this is easier to understand because everything is explicit 
and uses the normal syntax.
Only functions that really use the mode need to be parametrized.
It requires no change to the compiler, so its simpler for Walter.
It does require a little more typing for the function writer but not much.
No change is necessary for the use of the function since it 
automatically picks up the current rounding mode.
Additionally it does not affect functions that don't need it like your 
module setting would.
That way you don't need to segregate all the functions that use the 
rounding mode into a separate module to avoid penalizing the others.

To be clear, I do understand your suggestion and believe it would work.
I just prefer not to add new elements to the language when there is a
reasonably good solution already available.

Phil.