Floating point rounding modes: we should restrict them slightly

Don nospam at nospam.com
Mon Sep 14 02:26:39 PDT 2009


Rainer Deyke wrote:
> Don wrote:
>> The pure function memoisation issue:
>> Certain functions may be marked as 'pure', even though they use floating
>> point (and are therefore dependent on the FP state). The compiler must
>> be able to prevent memoisation of those functions in cases where the
>> rounding mode may have changed. (Or, equivalently, the memoisation must
>> include the FP state).
> 
> Don't forget that "uses floating point" is a transitive property.  Any
> pure function that calls a pure-but-unmemoisable function is itself
> pure-but-unmemoisable.

This is incorrect. You've got it backwards. It's not "uses floating 
point" that's the issue, it's "may use non-default floating point". A 
memoisable floating point function can only use default floating point. 
So, if it calls a non-memoisable pure function, it'll be using it in the 
default state (even though that function can accept non-default state).

The transitivity propagates in the reverse direction: memoisability is 
transitive, non-memoisability is not. Non-memoisable functions cannot 
call memoisable ones without first ensuring that everything is back into 
the default state.

   The "pure" annotation is now used for two
> related but different categories of functions with different properties,
> and the compiler needs some way to keep track of which is which across
> module boundaries.  If the compiler can do that, then it can use the
> same mechanism to differentiate between pure and non-pure functions, and
> the "pure" annotation becomes redundant.

It's true that you could provide a similar loophole for any specific 
global variable. But you'd need a *very* good reason.

> Is there any real need to treat floating point state differently from
> other global state in regard to "pure"?

Yes. Because it's all-pervasive. Unless you treat it specially, you 
cannot use floating point in any pure function. That creates a 
restriction which is so severe that 'pure' becomes useless. Something 
like the following template function could not be pure:

T add(T a, T b) { return a + b; }

I do not believe that any other global state has an influence which is 
in the same league.



More information about the Digitalmars-d mailing list