Rainer Deyke wrote:
Don wrote:
Ah. The important thing that makes this work is that the global FP state
has a clearly defined default. (round-to-nearest, full precision, no
floating point exceptions enabled). Part of the implicit contract of
calling a 'memoisable pure' function is that the global FP state is in
the default state.
Then I'm not sure it makes to treat "memoisable" as a property of a
(pure) function. It seems more like a property of the context from
which the function is called. *All* pure function are memoisable if you
always call them with the floating point rounding mode set to the
default. Conversely, all pure functions can be called with an arbitrary
rounding mode if you treat them an unmemoisable.
That is correct.
Some function - those that don't perform any floating point calculation,
directly or indirectly - are independent from floating point state, and
could even memoised even when called with an arbitrary floating point
state. But there is no good way to automatically detect these functions.
It sounds as though you never saw my proposal. My proposal was that, by
analogy to module(system), specific modules should be marked, for example:
module (advancedfloatingpoint, system) std.math;
or:
module (nondefaultfloat, system) std.math;
All pure functions are memoisable except for pure advancedfloatingpoint
functions when called from a function (pure or not) which is also in an
advancedfloatingpoint module.
This is a very tiny hole in the 'purity' rules, and is a tiny addition
to the language, but it's enough to cover the practical uses of
floating-point rounding and exception flags.
