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

From: John Maddock (john_at_[hidden])
Date: 2007-06-13 05:14:41

David Abrahams wrote:
>> 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<throw_on_error>,
>        pole_error<throw_on_error>,
>        overflow_error<throw_on_error>,
>        evaluation_error<throw_on_error>,
>        denorm_error<ignor_error>,
>        underflow_error<ignor_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<integer_outside_edge>
>        >
>   {};
>
> ?
> That will keep your type names under control.

Interesting idea.  Actually as far as the code internals are concerned the 
only thing that matters are the member typedefs of the policy class used, so 
this should "just work".... but one of things I was planning on doing is 
"normalising" the policy class passed to the function: basically decompose 
it and then recompose in a particular order: that way if the same function 
is called with different policy types that actually name the same policies, 
then internally only one template gets instantiated and we reduce code 
bloat.  The same mechanism can stip out policies that have no relevence to 
the function being called, again potentially reducing code bloat.  At 
present I don't see a way to combine that with your inheritance mechanism. 
I also need to be able to inject certain computed policies into the policy 
object when it get's normalised (basically a combination of the existing 
policy and it's combination with the actual real-number type being used for 
the computation).

I do have a Boost.Format based mechanism to create nicely formatted function 
names though - and yes only invoked when needed - so I guess the question is 
whether these long mangled names have any other consequences: compile and or 
link time for example?

Thanks, John.