-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thijs van den Berg Sent: 22 November 2008 14:48 To: boost@lists.boost.org Subject: Re: [boost] [math distributions] where to check for validity of distribution variables?
John Maddock wrote:
Thijs van den Berg wrote:
> What do you think? We might turn "having valid parameters" into > a property of *all* distribution. As an alternative, we might add > a non member function bool valid<distributionType... > but that wouldn't allow for caching validation in e.g. a > constructor
Sounds fine to me. thats great! What's your opinion on the fact that you can only set parameter in the constructor? E.g. the normal distribution does a parameter check in the constructor, and those parameters can't change after that.
That's what the existing distributions do. In fact we could omit most of the subsequent parameter checking code if we could figure out whether the error handlers will throw or not on error (in fact we *can* get this information at compile time and make the subsequent checks a no-op if we know that the constructor would have thrown on error... we just ran out of time on that refinement).
I don't understand this, it has to do with my lack of knowledge on this... If you ensure that the parameters get checked in the constructor, why would that check *not* throw an error when needed?
Often you just want to return a NaN, infinity or a 'best guess'. So John devised the rather complicated - but very useful - policies. Most important they are needed to provide the C++ Standard library C-style error behaviour. enum error_policy_type { throw_on_error = 0, // throw an exception. errno_on_error = 1, // set ::errno & return 0, NaN, infinity or best guess.. ignore_error = 2, // return 0, NaN, infinity or best guess. user_error = 3 // call a user-defined error handler.
Compile time might be tricky depending on the complicity of the parameter validation code, but simple range check on the parameters could be done compile time. What mechanism are your thinking about regarding compile checking, e.g. that scale>0?
The complexity of policy options make it much simpler to do a run-time check. You'd save a tiny bit on run-time - but probably pay in compile time? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com