Re: [boost] math/statistics policy-interface feedback requested.

From: John Maddock (john_at_[hidden])
Date: 2007-06-19 12:39:19

Hubert Holin wrote:

> The proposed interface is certainly nice and could definitely be
> worked with.

OK good.

> For the global choices it is perfectly adequate, IMO. For finer
> control however, it does appear very fine-grained (per-function),
> which, in addition to making error message harder to read, is perhaps
> not the most frequent level of interaction needed. For instance,
> while I certainly see the need sometimes for per-function disabling
> of internal double promotion, I believe that more frequently users
> may want to set these preferences at the translation unit level, when
> not at the global level.

Whilst I think you're correct that per-TU control is the most often needed 
requirement: it's actually the hardest of all to provide without violating 
the dreaded "one definition rule".  The only solution I can think of 
involves making the special function macros - which also means we can't 
overload them - and then internally mangling the function names according to 
the policies in effect (in other words the same as the current proposal).

Perhaps more interesting, and based on the current proposal is per-namespace 
policies:

#include <boost/math/special_functions.hpp>

typedef something my_policy_type;

namespace mynamespace{
BOOST_MATH_DECL_POLICY_SPECIAL_FUNCTIONS(my_policy_type);
}

Then "mynamespace::tgamma(x);" would use my_policy_type to determine it's 
behaviour.

If you an unnamed namespace then this could be used in place of a using 
declaration, to bring a specific set of functions into the scope of the 
current TU only.

> While (mostly) global objects may be evil, something along the
> lines of standard streams and their interaction with locales and
> facets may perhaps be easier to deal with. For instance, functions
> may requests their choices from some external "policy object", which
> may be locally altered, much as streams will enquire from a locale
> how to typeset dates. Granted, this would make multithreading all the
> hairier (which is not really a good idea).

Oh, no global objects please, they're evil, no really they are!  :-)

> On the other hand, not all
> functions necessarily require information about every configuration
> choice possible, so passing in all the info when only some is needed
> may perhaps be excessive.

That's true.  However, I now have the meta-programming code that allows a 
function to reset policies that it knows aren't relevent to it to their 
defaults.  Policy objects also get "normalised" internally to reduce code 
bloat, so:

tgamma(x, policy1);

and

tgamma(x, policy2);

are one-line inline forwarders that will call the same template 
instantiations internally, if there are no relevent differences between 
policy1 and policy2.

Thanks for the feedback, John.