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

on Tue Jun 12 2007, "John Maddock" wrote:

define a typedef of the policy class:

using namespace boost::math::policy; typedef policy< // Set error handling: domain_error, pole_error, overflow_error, evaluation_error, denorm_error, underflow_error, // calculate to 8 decimal digits internally digits10<8>, // don't promote double->long double for accuracy promote_double<false>, // Integer quantiles return the "outside edge": // below the real value for lower critical values, // above it for upper critical values, so that the // area inside contains *at least* the requested coverage: discrete_quantile > fast_quantile_policy;

static fast_quantile_policy fast_quantile;

Then we can just use:

quantile( poisson(100), 0.05, fast_quantile);

In our actual code.

Currently this policy interface is vapourware: I have enough of a prototype implemented to know that it's possible to achieve this syntax (this is revision #3 already !), but there's a lot of hairy meta-programming to convert that into something that the library's internals can make use of... so I'd like to know what folks think before I invest too much time messing about with MPL :-)

The main disadvantage I've noticed at present, is that the mangled names of the policy class - and therefore all the special functions etc - are *very* long.

Why not make it allowable to use derivation: struct fast_quantile_policy : policy< // Set error handling: domain_error, pole_error, overflow_error, evaluation_error, denorm_error, underflow_error, // calculate to 8 decimal digits internally digits10<8>, // don't promote double->long double for accuracy promote_double<false>, // Integer quantiles return the "outside edge": // below the real value for lower critical values, // above it for upper critical values, so that the // area inside contains *at least* the requested coverage: discrete_quantile > {}; ? That will keep your type names under control.

This has an impact on error messages: in particular we currently use BOOST_CURRENT_FUNCTION to get a nice formatted name of a function that's about to throw, but with function names a couple of pages long I don't think that will be possible with this interface any more :-(

-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com