Proposal: fixing the 'pure' floating point problem.

Don nospam at nospam.com
Sun Mar 15 06:10:44 PDT 2009


Don wrote:
> Walter Bright wrote:
>> Don wrote:
>>> The math functions need to work for any rounding mode, not just the 
>>> default mode. They also set the status flags correctly. In fact, they 
>>> are almost the only functions where this matters!
>>
>> Ok, then std.math functions cannot be pure in either your or my 
>> proposal, so I'm not seeing the advantage of yours.
> 
> They _can_ be pure in my proposal.
> 
> Take  real y = exp(real x) as an example.
> 
> Actually what happens is:
> y = exp(real x, threadlocal int controlflags);
> threadlocal int statusflags |= exp_effect_statusflags(real x, 
> threadlocal int controlflags);


Or to put it another way -- in my proposal, we acknowledge that these 
two hidden variables always exist, in every function, and must be 
treated correctly for all pure functions.

The module(floatingpoint)(or better, module(advancedfloatingpoint)) is 
essentially an optimisation trick, severely restricting access to those 
hidden variables. It allows the compiler to completely ignore the hidden 
variables in every module except for a small number of designated 
modules. These designated modules are so rare, that they can be dealt 
with by disabling caching of pure function return values.

I would expect that apart from std.math, there'd be very few other 
advancedfloatingpoint modules, other than those explicitly dealing with 
interval arithmetic, and those dealing with particular array operations.

Easy to implement, easy to explain to users (if you want to use the 
advanced floating point features, define the 
module(advancedfloatingpoint). Any public function in such a module must 
restore the rounding mode back to the default before returning, and 
before calling any function which is not defined in an 
advancedfloatingpoint module. Any call to a function which is not in an 
advancedfloatingpoint module leaves the floating point sticky flags in 
an undefined state).

Frankly, I think this is one of my best ever language proposals. I'd 
considered much more complicated approaches and discovered that they 
didn't work. I was very proud to have found such a simple solution.

The difficult bit is convincing people that it actually solves the 
problem, and that almost nothing else works. <g>



More information about the Digitalmars-d mailing list