Boost C++ Libraries: Ticket #9126: Logistic distribution pdf() and cdf(complement()) fail to catch invalid scale and location parameters

owner, status, milestone changed

Paul A. Bristow — Wed, 18 Sep 2013 17:11:19 GMT

owner changed from John Maddock to Paul A. Bristow
status new → assigned
milestone To Be Determined → Boost 1.55.0

Thanks for reporting this which should be fixed for 1.55.

Paul A. Bristow — Thu, 19 Sep 2013 13:07:44 GMT

Have you an actual use example or test case for this condition (or is this comment just from examination of the code)?

Thu, 19 Sep 2013 15:41:21 GMT

I have wrappers around boost:

#include <boost/math/distributions/logistic.hpp>
double logistic_pdf( double dX, double dL, double dS )
{
	// logistic distribution object:
	boost::math::logistic logis(dL, dS);
	return pdf(logis, dX);
}
double logistic_utp( double dX, double dL, double dS )
{
	// logistic distribution object:
	boost::math::logistic logis(dL, dS);
	return cdf(complement(logis, dX));
}

These test cases should error, but return 0.0:

logistic_pdf(Pc_PosInf, Pc_PosInf, 1.0);
logistic_pdf(Pc_PosInf, 0.0, Pc_PosInf);
logistic_pdf(Pc_PosInf, 0.0, 0.0);
logistic_utp(Pc_PosInf, Pc_PosInf, 1.0);
logistic_utp(Pc_PosInf, 0.0, Pc_PosInf);
logistic_utp(Pc_PosInf, 0.0, 0.0);

Thu, 19 Sep 2013 15:43:04 GMT

I should have included:

#define Pc_PosInf (std::numeric_limits<double>::infinity())

Paul A. Bristow — Fri, 20 Sep 2013 09:47:33 GMT

Fixed in boost trunk at https://svn.boost.org/svn/boost/trunk/boost/math/distributions/logistic.hpp

(you could download this version).

SVN commit 87950

but I am still puzzled why the checks in the distribution object constructor didn't catch these tests.

Did you change the default policy (from 'to throw exception') to ignore errors?

Did you use try'n'catch blocks so that the error messages appear? (as always recommended).

Did you get the same in debug and release (optimised) version?

Should make boost release 1.55.

Fri, 20 Sep 2013 16:01:53 GMT

I apologize, I should have included my user.hpp settings. I've tried to attach my user.hpp file but Trac rejects it as spam. I've included the relevant portions here:

//
// Default policies follow:
//
// Domain errors:
//
// #define BOOST_MATH_DOMAIN_ERROR_POLICY throw_on_error
#define BOOST_MATH_DOMAIN_ERROR_POLICY ignore_error
//
// Pole errors:
//
// #define BOOST_MATH_POLE_ERROR_POLICY throw_on_error
#define BOOST_MATH_POLE_ERROR_POLICY ignore_error
//
// Overflow Errors:
//
// #define BOOST_MATH_OVERFLOW_ERROR_POLICY throw_on_error
#define BOOST_MATH_OVERFLOW_ERROR_POLICY ignore_error
//
// Internal Evaluation Errors:
//
// #define BOOST_MATH_EVALUATION_ERROR_POLICY throw_on_error
#define BOOST_MATH_EVALUATION_ERROR_POLICY ignore_error
//
// Underfow:
//
// #define BOOST_MATH_UNDERFLOW_ERROR_POLICY ignore_error
//
// Denorms:
//
// #define BOOST_MATH_DENORM_ERROR_POLICY ignore_error
//
// Max digits to use for internal calculations:
//
// #define BOOST_MATH_DIGITS10_POLICY 0
//
// Promote floats to doubles internally?
//
// #define BOOST_MATH_PROMOTE_FLOAT_POLICY true
//
// Promote doubles to long double internally:
//
// #define BOOST_MATH_PROMOTE_DOUBLE_POLICY true
//
// What do discrete quantiles return?
//
// #define BOOST_MATH_DISCRETE_QUANTILE_POLICY integer_round_outwards
//
// If a function is mathematically undefined
// (for example the Cauchy distribution has no mean),
// then do we stop the code from compiling?
//
// #define BOOST_MATH_ASSERT_UNDEFINED_POLICY true
//
// Maximum series iterstions permitted:
//
// #define BOOST_MATH_MAX_SERIES_ITERATION_POLICY 1000000
//
// Maximum root finding steps permitted:
//
// define BOOST_MATH_MAX_ROOT_ITERATION_POLICY 200
// [PJM] Needed for students_t_ltq(), students_t_utq()
// [PJM] changed with fix to Ticket #8837
//#define BOOST_MATH_ROUNDING_ERROR_POLICY ignore_error

Paul A. Bristow — Mon, 23 Sep 2013 09:56:28 GMT

Ah ha, as I eventually suspected, you are ignoring the carefully constructed error reporting mechanism :-)

I trust that the code changes will meet your wishes, but one could argue that the more correct result from 'bad' distribution constructor arguments is always NaN (not infinity). You could define your custom policy to achieve just that. Or you could use the default error handling policy and throw'n'catch from the distribution construction - the intended usage, as given in many examples.

John Maddock — Sat, 28 Sep 2013 16:19:56 GMT

(In [85987]) Merge accumulated patches from Trunk. Refs #8384, Refs #8855, refs #9107, refs #9109, refs #8333, refs #8621, refs #8732, refs #8733, refs #8837, refs #8940, refs #9042, refs #9087, refs #9104, refs #9126.

status changed; resolution set

John Maddock — Sun, 22 Dec 2013 17:05:45 GMT

status assigned → closed
resolution → fixed