Re: [Boost-users] Boost.Math.StatisticalDistributions

From: John Maddock (john_at_[hidden])
Date: 2008-03-06 05:07:49

johneddy101_at_[hidden] wrote:
>> Hello,
>> I realize that this library is not yet part of the boost
>> distribution but I am using it and have come accross an issue.  I am
>> concerned that the logic in the various check functions may be
>> flawed.  Take for example the check_uniform function.  The logic is
>> as follows:
>> if  lower Ok && upper Ok && lower < upper
>>     return true
>> else
>>     raise error stating that lower must be less than upper
>>     return false
>> end if
>>
>> The functions used to determine if lower and upper are ok will raise
>> errors if appropriate.  If the policy is such that raising an error
>> does not cause a throw, then control will return to the
>> check_uniform method with an indication that lower or upper is not
>> ok and we will enter the else block.  Herein lies the problem.
>> Consider the following scenario: creating a uniform distribution
>> with:
>> lower = 0.0
>> upper = postitive infinity
>> Check upper will fail and send a message about the infinity.  Enter
>> the else block.
>> A message will be raised that states that the lower parameter is not
>> less than the upper.
>> This is my concern.  I believe the second message is unnecessary and
>> potentially incorrect/misleading.  Perhaps logic like shown below
>> would be more appropriate:
>> if lower not Ok || upper not Ok then
>>     return false
>> else if lower >= upper
>>     raise error stating that lower must be less than upper
>>     return false
>> else
>>     return true
>> end if

Yep, will change as suggested: note however you can only actually observe 
the domain_error handler being called twice (with different messages) if you 
are using a user-defined error handler *and* that handler doesn't throw an 
exception.

Paul, I think this one was one of yours?  Are we likely to need to give the 
other distros a once-over to check we don't do this elsewhere as well?

Thanks for spotting this, John.