boostorg / math

Boost.org math module

Boost Math Library

ANNOUNCEMENT: This library requires a compliant C++14 compiler.

	Master	Develop
Drone
Github Actions
Codecov

The Math library provides numerous advanced mathematical functions implemented in modern C++. The library strives to deliver the utmost in numerical and syntactical correctness while still maintaining high-performance.

All code is header-only, facilitating easy client setup and use throughout the entire diverse collection of functions.

The library is divided into several interconnected parts:

Floating Point Utilities

Utility functions for dealing with floating point arithmetic, includes functions for floating point classification (fpclassify, isnan, isinf etc), sign manipulation, rounding, comparison, and computing the distance between floating point numbers.

Specific Width Floating Point Types

A set of typedefs similar to those provided by <cstdint> but for floating point types.

Mathematical Constants

A wide range of constants ranging from various multiples of π, fractions, Euler's constant, etc.

These are of course usable from template code, or as non-templates with a simplified interface if that is more appropriate.

Statistical Distributions

Provides a reasonably comprehensive set of statistical distributions, upon which higher level statistical tests can be built.

The initial focus is on the central univariate distributions. Both continuous (like normal & Fisher) and discrete (like binomial & Poisson) distributions are provided.

A comprehensive tutorial is provided, along with a series of worked examples illustrating how the library is used to conduct statistical tests.

Special Functions

Provides a wide range of high quality special functions; initially these were concentrated on functions used in statistical applications along with those in the Technical Report on C++ Library Extensions.

The function families currently implemented are the gamma, beta and error functions along with the incomplete gamma and beta functions (four variants of each) and all the possible inverses of these, plus the digamma, various factorial functions, Bessel functions, elliptic integrals, hypergeometrics, sinus cardinals (along with their hyperbolic variants), inverse hyperbolic functions, Legrendre/Laguerre/Hermite/Chebyshev polynomials and various special power and logarithmic functions.

All the implementations are fully generic and support the use of arbitrary "real-number" types, including those in Boost.Multiprecision. Most functions are, however, optimized for use with types with known significand (or mantissa) sizes: typically built-in float, double or long double.

These functions also provide the basis of support for the TR1 special functions, many of which became standardized in C++17.

Root Finding

A comprehensive set of root-finding algorithms over the real line, both with derivatives and derivative free.

Optimization

Minimization of cost functions via Brent's method and differential evolution.

Polynomials and Rational Functions

Tools for manipulating polynomials and for efficient evaluation of rationals or polynomials.

Interpolation

Function interpolation via barycentric rational interpolation, compactly supported quadratic, cubic, and quintic B-splines, the Chebyshev transform, trigonometric polynomials, Makima, pchip, cubic Hermite splines, and bilinear interpolation.

Numerical Integration and Differentiation

A reasonably comprehensive set of routines for integration (trapezoidal, Gauss-Legendre, Gauss-Kronrod, Gauss-Chebyshev, double-exponential, and Monte-Carlo) and differentiation (Chebyshev transform, finite difference, the complex step derivative, and forward-mode automatic differentiation).

The integration routines are usable for functions returning complex results - and hence can be used for computation of contour integrals.

Quaternions and Octonions

Quaternion and Octonion are class templates similar to std::complex.

The full documentation is available on boost.org.

Standalone Mode

Defining BOOST_MATH_STANDALONE allows Boost.Math to be used without any Boost dependencies. Some functionality is reduced in this mode. A static_assert message will alert you if a particular feature has been disabled by standalone mode. Standalone mode is not designed to be used with the rest of boost, and may result in compiler errors.

Supported Compilers

The following compilers are tested with the CI system, and are known to work. Currently a compiler that is fully compliant with C++14 is required to use Boost.Math.

• g++ 5 or later
• clang++ 5 or later
• Visual Studio 2015 (14.0) or later

Support, bugs and feature requests

Bugs and feature requests can be reported through the GitHub issue tracker (see open issues and closed issues).

You can submit your changes through a pull request.

There is no mailing-list specific to Boost Math, although you can use the general-purpose Boost mailing-list using the tag [math].

Development

Clone the whole boost project, which includes the individual Boost projects as submodules (see boost+git doc):

$ git clone https://github.com/boostorg/boost
$ cd boost
$ git submodule update --init

The Boost Math Library is located in libs/math/.

Running tests

First, make sure you are in libs/math/test. You can either run all the tests listed in Jamfile.v2 or run a single test:

test$ ../../../b2                        <- run all tests
test$ ../../../b2 static_assert_test     <- single test
test$ # A more advanced syntax, demoing various options for building the tests:
test$ ../../../b2 -a -j2 -q --reconfigure toolset=clang cxxflags="--std=c++14 -fsanitize=address -fsanitize=undefined" linkflags="-fsanitize=undefined -fsanitize=address"

Continuous Integration

The default action for a PR or commit to a PR is for CI to run the full complement of tests. The following can be appended to the end of a commit message to modify behavior:

* [ci skip] to skip all tests
* [linux] to test using GCC Versions 5-12 and Clang Versions 5-14 on Ubuntu LTS versions 18.04-22.04.
* [apple] to test Apple Clang on the latest version of MacOS.
* [windows] to test MSVC-14.0, MSVC-14.2, MSVC-14.3, CYGWIN, and mingw on the latest version of Windows.
* [standalone] to run standalone mode compile tests

Building documentation

Full instructions can be found here, but to reiterate slightly:

libs/math/doc$ brew install docbook-xsl # on mac
libs/math/doc$ touch ~/user-config.jam
libs/math/doc$ # now edit so that:
libs/math/doc$ cat ~/user-config.jam
using darwin ;

using xsltproc ;

using boostbook
    : /usr/local/opt/docbook-xsl/docbook-xsl
    ;

using doxygen ;
using quickbook ;
libs/math/doc$ ../../../b2

math's Issues

error in documentation

On this page: ​https://www.boost.org/doc/libs/1_66_0/libs/math/doc/html/math_toolkit/stat_tut/weg/st_eg/two_sample_students_t.html in a table with headings "Hypothesis" and "Test" on the rows for "no difference" and "difference" hypotheses, the sample code is the same. Probably, on the "difference" row, there should be a "greater than" sign.

Moved from Trac

Noncentral chi-squared distribution with 0 degrees of freedom

Boost returns an error when we supply 0 for the degrees of freedom of chi-squared distribution:

#include <iostream>
#include <cmath>
#include "boost/math/distributions/non_central_chi_squared.hpp"

int main(){
    std::cout << boost::math::cdf(boost::math::non_central_chi_squared(0, 1), 1);
    return 0;
}

Error in function boost::math::non_central_chi_squared_distribution::non_central_chi_squared_distribution(double,double): Degrees of freedom argument is 0, but must be > 0 ''

However this distribution makes sense. It has a density.

Moved from Trac.

Division by zero in Schroeder iterate

Code to reproduce:

#include <iostream>
#include <vector>
#include <string>
#include <boost/math/tools/polynomial.hpp>
#include <boost/math/tools/roots.hpp>
#include <boost/math/special_functions/binomial.hpp>

using std::string;
using boost::math::tools::polynomial;
using boost::math::binomial_coefficient;
using boost::math::tools::schroder_iterate;

template<class Real>
void daubechies_coefficients(size_t p)
{
    std::vector<Real> coeffs(p);
    for (size_t k = 0; k < coeffs.size(); ++k) {
      coeffs[k] = binomial_coefficient<Real>(p-1+k, k);
    }

    polynomial<Real> P(coeffs.begin(), coeffs.end());
    polynomial<Real> P_prime = P.prime(); // Basically syntactic sugar from the PR
    polynomial<Real> P_dprime = P_prime.prime();

    auto f = [&](Real x)->std::tuple<Real, Real, Real>
    {
        return std::make_tuple<Real, Real, Real>(P(x), P_prime(x), P_dprime(x));
    };

    Real guess = 0;
    Real minimum = -100000;
    Real maximum = 100000;
    boost::uintmax_t digits = std::numeric_limits<Real>::digits10;
    boost::uintmax_t iterations = 15;
    Real r = schroder_iterate(f, guess, minimum, maximum, digits, iterations);
    std::cout << "Root: " << r << ", P(r) = " << P(r) << std::endl;
}

int main()
{
    daubechies_coefficients<double>(8);
}

Compile with:

$ clang++ --std=gnu++17 -O0 -g -fsanitize=address -fsanitize=undefined -Wall -Wfatal-errors -march=native main.cpp

Error message:

include/boost/math/tools/roots.hpp:519:19: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/boost/math/tools/roots.hpp:519:19

Polynomial feature requests

Couple of things I could use for working with polynomials:

1. Instead of p.evaluate(x), it would be nice to be able to simply write p(x). That would allow passing the polynomial directly into various functionals, like root-finding and quadrature.

2. It would be nice to have a move constructor from std::vector<T>, since the storage format is std::vector<T> and after you've constructed the coefficients and passed them into the polynomial, you don't really need them anymore.

3. I'd like to be able to write polynomial<Real> q = p.prime() to get the derivative of the polynomial.

4. It would be nice to be able to write auto r = p.roots(). Well, that's a challenging problem since it's ill-conditioned. But Trefethen has shown that if you represent a polynomial as a Chebyshev series, then there exists a fast algorithm to compute the roots. (More info here, here, and here.)

5. p.integrate().

6. I didn't know that this had a .chebyshev() method, so it'd be nice to know if it was compatible with the Chebyshev transform.

7. We should be able to template on a complex type.

I'm writing this just to remind myself of features I want as I use them; most of these are trivial so I'll try to write them as I encounter them.

redundant check in ellint_f_imp?

on line 118ish there is a code snippet which looks like

       T sinp = sin(rphi);
       sinp *= sinp;
       T cosp = cos(rphi);
       cosp *= cosp;
       BOOST_MATH_INSTRUMENT_VARIABLE(sinp);
       BOOST_MATH_INSTRUMENT_VARIABLE(cosp);
       if(sinp > tools::min_value<T>())
       {
          //
          // Use http://dlmf.nist.gov/19.25#E5, note that
          // c-1 simplifies to cot^2(rphi) which avoid cancellation:
          //
          T c = 1 / sinp;
          result = rphi == 0 ? static_cast<T>(0) : static_cast<T>(s * ellint_rf_imp(T(cosp / sinp), T(c - k * k), c, pol));
       }
       else
          result = s * sin(rphi);

I can't see a scenario in which rphi==0 could ever be true. If rphi==0 then sinp should also be zero for any canonical implementation of sin that I can think of. This means that if rphi==0 the sinp > tools::min_value<T>() check would have already failed (For any sensible implementation of min_value I can think of, keeping in mind the type can presumably store zero in order to be comparable to zero).

It looks like the check on sinp was added in 61cc79b and prior to this change the rphi==0 check would presumably be required but insufficient. With this check I think it's now redundant.

The use of deprecated boost/detail/endian.hpp

In file included from ../../../../boost/math/special_functions/sign.hpp:18:
In file included from ../../../../boost/math/special_functions/detail/fp_traits.hpp:27:
In file included from ../../../../boost/detail/endian.hpp:9:
../../../../boost/predef/detail/endian_compat.h:11:9: warning: The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER is deprecated. Please include <boost/predef/other/endian.h> and use BOOST_ENDIAN_*_BYTE instead [-W#pragma-messages]
#pragma message("The use of BOOST_*_ENDIAN and BOOST_BYTE_ORDER is deprecated. Please include <boost/predef/other/endian.h> and use BOOST_ENDIAN_*_BYTE instead")
        ^

Undefined behavior in tanh-sinh tests:

Testing right limit infinite for tanh_sinh in 'A Comparison of Three High Precision Quadrature Schemes' on type boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1>
/usr/local/include/boost/multiprecision/cpp_dec_float.hpp:434:34: runtime error: negation of -9223372036854775808 cannot be represented in type 'boost::long_long_type' (aka 'long long'); cast to an unsigned type to negate this value to itself
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/local/include/boost/multiprecision/cpp_dec_float.hpp:434:34 in

Not sure if this is a bug in multiprecision or tanh-sinh, need to investigate more . . .

UB in big_constant.hpp and error_handling.hpp:

Probably low priority, but some UB in big_constant.hpp and error_handling.hpp:

$  ../../../b2 -a --reconfigure cxxflags="--std=c++14 -fsanitize=address -fsanitize=undefined" linkflags="-fsanitize=address -fsanitize=undefined" test_2F0
../../../boost/math/tools/big_constant.hpp:43:26: runtime error: -2.79443e+39 is outside the range of representable values of type 'float'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../../boost/math/tools/big_constant.hpp:43:26 in
../../../boost/math/policies/error_handling.hpp:803:26: runtime error: -2.79443e+39 is outside the range of representable values of type 'float'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../../boost/math/policies/error_handling.hpp:803:26 in

Issue with computing quantiles for skew-normal

The 0.075 skew-normal quantile breaks (returns an inf) with certain, seemingly reasonable parameters. Other surrounding values are okay. The complemented version works for some reason.

Here's some test code

#include <iostream>
#include <boost/math/distributions.hpp> 

int main()
{
    boost::math::skew_normal_distribution<> dist(2.0, 1.0, -2.5);

    std::vector<double> qs = { 0.05, 0.075, 0.1 };
    for(auto q : qs) {
        std::cout << "q : " << q << std::endl;
        std::cout << "w/o complement: " << quantile(dist, q) << std::endl;
        std::cout << "w complement: " << quantile(complement(dist, 1 - q)) << std::endl << std::endl;
    }
}

Dunno how easy this is to fix. I can work around it where I'm using it, but it seems like something that could be fixed.

Thanks!

Moved from Trac.

Robust convergence tests for double exponential quadrature

The double exponential quadrature we have is very good, but nonetheless, JSIAM gave an award for the following publication:

https://www.jstage.jst.go.jp/article/jsiamt/13/2/13_KJ00001032865/_pdf/-char/ja

which of course I cannot read. It appears that there is a way to estimate the discretization error in a much more robust way than we are currently doing. This I think can safely sit on the todo list for quite some time, but I don't want to forget about it completely.

Redundant condition in ellint_pi_imp?

In 47c2f92 this code was added

   if(v == 1)
   {
      ...
      return result;
   }

Later in the method the following code appears

   if(k == 0)
   {
      // A&S 17.7.20:
      if(v < 1)
      {
         T vcr = sqrt(vc);
         return atan(vcr * tan(phi)) / vcr;
      }
      else if(v == 1)
      {
         return tan(phi);
      }

It seems to me that that else if(v == 1) will never be true because if it were, the first check for v==1 would have been hit.

The simplest solution would be to recognize that this code will not execute and remove it. However the expression it uses for k=0,v=1 seems a lot simpler than the expression being used currently so perhaps it would be better to rearrange the cases.

Variance for naive_monte_carlo is incorrect, leading to greatly inflated numbers of samples

I don't see the bug off hand, so this is probably one for @NAThompson .

If I test naive_monte_carlo with a simple Pi calculator:

   auto g = [](std::vector<double> const & x)->double
   {
      double r = x[0] * x[0] + x[1] * x[1];
      if (r <= 1)
      {
         return 1;
      }
      return 0;
   };

Then naive_monte_carlo::variance() reports ~2.7, but I believe the correct variance is 0.16, this can be checked with something like:

      using namespace boost::accumulators;
      boost::random::taus88 t(123455677);
      accumulator_set<double, stats<tag::variance> > acc1;

      for (unsigned i = 0; i < count; ++i)
      {
         double x, y;
         x = boost::random::uniform_real_distribution<double>(-1, 1)(t);
         y = boost::random::uniform_real_distribution<double>(-1, 1)(t);
         double val = x * x + y * y <= 1 ? 1 : 0;
         acc1(val);
      }

      std::cout << "Mean = " << boost::accumulators::mean(acc1) << std::endl;
      std::cout << "Variance = " << variance(acc1) << std::endl;

As a consequence, if you specify an error bound of say 1e-3, you get an error estimate of 8e-4, and an actual error of 4e-5. In other words there is some gross over-sampling going on here.

Found while testing/comparing to CUDA version which calculates the variance differently.

Assertion Failure in tanh_sinh.hpp

Code to reproduce:

#include <boost/math/constants/constants.hpp>
#include <boost/multiprecision/cpp_bin_float.hpp>
#include <boost/math/quadrature/tanh_sinh.hpp>

using boost::multiprecision::cpp_bin_float_quad;


template<class Real>
void test_omega()
{
    using std::sin;
    using std::cos;
    using boost::math::quadrature::tanh_sinh;
    using boost::math::constants::two_pi;
    auto f = [](Real x)->Real {
        return (1+2*cos(x)+x*sin(x))/(1+2*x*sin(x)+x*x);
    };

    tanh_sinh<Real> ts;
    Real t = ts.integrate(f, (Real) 0, 100*two_pi<Real>());
}


int main()
{
    test_omega<cpp_bin_float_quad>();
    return 0;
}

Failure message:

clang++ --std=c++1z -Wfatal-errors -I./include reproduce.cpp -o reproduce.x -pthread -lbenchmark
Assertion failed: (position != b), function operator(), file ./include/boost/math/quadrature/tanh_sinh.hpp, line 170.
[1]    76470 abort      ./reproduce.x

Commenting out line 170 of this file fixes the problem, but perhaps only because the integrand isn't singular at the endpoints.

Non UTF-8 files in Math library

The Math library contains two non UTF-8 files (in both cases a comment which contains a Windows CP1252 dash).

Here the output of the "file" command:

boost/math/special_functions/detail/bessel_i0.hpp: C++ source, Non-ISO extended-ASCII text boost/math/special_functions/detail/bessel_i1.hpp: C++ source, Non-ISO extended-ASCII text

This makes the files incompatible with modern Microsoft Compilers when using switch /utf-8.

The attached patch simply replaces the CP1252 dash with an ASCII dash and therefore fixes the issue for all compilers.

Moved from Trac.

unusual characters in lambert_w.hpp

Compiling boost-math fails under MSVC when using the /utf-8 command-line option. (This tells it to assume the source files are utf8 encoded.)
The error occurs on line 1865 of lambert_w.hpp which contains code page 1252 smart quotes (0x93, 0x94) and an en-dash (0x96) -
// �On the Lambert W function, � Adv.Comput.Math., vol. 5, pp. 329�359, 1996.

These 3 bytes, being followed by values in the range 0x00-0x7F, are invalid in utf8 encoding and hence the compiler complains.

Are boost source files specified to use Windows 1252 code page, or should compiling assuming utf-8 work ?

Very broad constructor in polynomial absorbing initializer list

I'm confused about the following constructor in polynomial.hpp:

   template <class U>
   explicit polynomial(const U& point)
   {
       if (point != U(0))
          m_data.push_back(point);
   }

This seems to be very broad, and have been called in surprising situations resulting in the build breaking. For instance, the following test:

polynomial<double> c{{10, -6, -4, 3}};

which you would hope gets passed to the initializer list constructor, in fact gets passed to the aforementioned constructor and causes the following error:

test_polynomial.cpp(88) : error C2440: 'initializing' : cannot convert from 'initializer-list' to 'boost::math::tools::polynomial<double>'
        Constructor for class 'boost::math::tools::polynomial<double>' is declared 'explicit'
test_polynomial.cpp(89) : error C2440: 'initializing' : cannot convert from 'initializer-list' to 'boost::math::tools::polynomial<double>'

So I would like to know what the purpose of this constructor is and its use case.

Problems about the valid domain of input k in ellint_1, ellint_2, ellint_3

Directory: boost/math/special_functions/
Files: ellint_1.hpp, ellint_2.hpp, ellint_3.hpp

For the 1st incomplete elliptic integral, ellint_f_imp(T phi, T k, Policy& pol) in file ellint_1.hpp, the function requires |k|<=1, which is not necessary. The only constraint is that the Carlson elliptic integral R_f, which is called in line 118, requires (c-k*k)>=0, where c=1/sinp is larger than 1. So the |k|<=1 constraint is too strong in this case. However, in line 80 and line 125, the complete elliptic integral ellint_k_imp is called. The complete elliptic integral requires |k|<1, and the result goes to infinity at |k|==1, which implies the |k|<=1 constraint in ellint_f_imp is too weak.

The appropriate domain region of k is given by NAG Library (where $m=k^2$):
https://www.nag.com/numeric/fl/nagdoc_fl22/xhtml/s/s21bef.xml
$k^2\sin^2\phi\leq 1$

The same problem exists in 2nd and 3rd incomplete elliptic integral as well.

I know the reason of this constraint is C++17's design, but it really causes some problem in numerical computation.

In C++17, function std::ellint_1 has error handling:
https://en.cppreference.com/w/cpp/numeric/special_math/ellint_1

Errors may be reported as specified in math_errhandling

If the argument is NaN, NaN is returned and domain error is not reported
If |k|>1, a domain error may occur

extreme value distribution's mean/std fail for location=0

Extreme value distribution's mean and standard_deviation use both detail::check_scale for location parameter a, which seems wrong, as there's no limitation for location parameter a (besides being finite).

This causes even a standard extreme value distribution to fail:

BOOST_AUTO_TEST_CASE(checkScaleIssueMean)
{
	boost::math::extreme_value_distribution<> G;

	boost::math::mean(G);
}

BOOST_AUTO_TEST_CASE(checkScaleIssueStd)
{
	boost::math::extreme_value_distribution<> G;

	boost::math::standard_deviation(G);
}

with

std::domain_error: Error in function boost::math::mean(const extreme_value_distribution<double>&): Scale parameter is 0, but must be > 0 !

std::domain_error: Error in function boost::math::standard_deviation(const extreme_value

Moved from Trac.

Implementation of 'chop' for the Chebyshev transform

When we implemented the truncation of the Chebyshev transform, it was based on a heuristic of Trefethen, and I believe it works very well. However, Trefethen has analyzed this problem in more detail:

https://people.maths.ox.ac.uk/trefethen/aurentz_trefethen_toms_final.pdf

I need to read this paper and make sure our Chebyshev series truncation is state-of-the-art.

Example tanh_sinh integrand broken

In tanh_sinh quadrature, the example integrand

auto f = [](double x) { return log(x)*log(1-x); };

gets evaluated at a singularity by tanh_sinh. I am not sure that this is surprising due to the low precision of evaluating log(1-x) near x=1. If this is the case then the docs should be updated to reflect the fact that this integrand needs the "2-argument functor" case, rather than the default.

It appears that auto f = [](double x)->double { return sqrt(log(1/x)); }; also gets evaluated at a singular point by Apple LLVM version 9.0.0 (clang-900.0.38).

Remove gcd tests from boost.math?

It appears that the gcd is tested in boost.integer, but the tests are somewhat different. Does it make sense to remove the gcd unit tests from boost.math?

Newton-Raphson and Halley iteration: Poor error reporting vs bisection

This is perhaps more of a design decision that a bug, but of course the close button is easy to press so I'll report it anyway:

When I give the boost::math::tools::bisect functional a function which is strictly positive everywhere (say, x^2 + 1), I get a very nice error message:

Error in function boost::math::tools::bisect<double>: No change of sign in boost::math::tools::bisect, either there is no root to find, or there are multiple roots in the interval (f(min) = 10001).

However, when I pass the same function into boost::math::tools::newton_raphson or boost::math::tools::halley_iterate, I don't get any error message at all. Instead, I get a root r returned, and the condition |f(r)| < eps doesn't hold at all.

My proposal is that before returning, newton_raphson and halley_iterate should check something like abs(f(r)) < thresh, and if it doesn't hold, then return std::numeric_limits<Real>::quiet_NaN().

maybe a bug in math::constants library

The following templated code will generate incorrect result in visual studio community 2017:

#include<iostream>
#include<boost/math/constants/constants.hpp>

// convienent defination of math constants
template<typename T> const T pi = boost::math::constants::pi<T>(); // PI
template<typename T> const T two_pi = boost::math::constants::two_pi<T>(); // 2*PI

// physical constants
template<typename T> const T mu_0 = 4.0*pi<T>*1.0e-4; // permeability of free space in H / km
int main()
{
	using T = double;
	auto w = two_pi<T> * 0.01;
	//auto t1 = pi<T>;
	auto t2 = mu_0<T>;
	std::cout<<"omega="<<w<<std::endl;
	std::cout<<"mu_0="<<t2<<std::endl;
	system("pause");

	return 0;
}

In VS2017, mu_0 will be 0.000. However, if I uncomment

auto t1 = pi<T>

in main, the result is correct. This problem does not happen when compiled with gcc 8.1 in Manjaro Linux. The boost library version is 1.67.0

Moved from https://svn.boost.org/trac10/ticket/13591

Add LambertW

Thomas Lui supplied the following code via email:

double plog(double x)
{
  if (x == 0) {
    return 0;
  }

  double w0, w1;
  if (x > 0) {
    w0 = log(1.2 * x / log(2.4 * x / log1p(2.4 * x)));
  } else {
    double v = 1.4142135623730950488 * sqrt(1 + 2.7182818284590452354 * x);
    double N2 = 10.242640687119285146 + 1.9797586132081854940 * v;
    double N1 = 0.29289321881345247560 * (1.4142135623730950488 + N2);
    w0 = -1 + v * (N2 + v) / (N2 + v + N1 * v);
  }

  while (true) {
    double e = exp(w0);
    double f = w0 * e - x;
    w1 = w0 - f / ((e * (w0 + 1) - (w0 + 2) * f / (w0+w0 + 2)));
    if (fabs(w0 / w1 - 1) < 1.4901161193847656e-8) {
      break;
    }
    w0 = w1;
  }

Update:

Thomas Lui provides better code in his thesis: ​http://discovery.ucl.ac.uk/1482128/1/Luu_thesis.pdf, see routine 11, and in Github as CUDA C++ device code: ​https://github.com/thomasluu/plog/blob/master/plog.cu.

We also have a more complex submission here: ​https://github.com/CzB404/lambert_w/ which includes support for complex numbered arguments.

Moved from https://svn.boost.org/trac10/ticket/11027

tools/config.hpp fixes

Hi,

Two items.

1. Commit cc8e300 commented out the following define in tools/config.hpp:

#if (defined(__CYGWIN__) || defined(__FreeBSD__) || defined(__NetBSD__) \
   || (defined(__hppa) && !defined(__OpenBSD__)) || (defined(__NO_LONG_DOUBLE_MATH) && (DBL_MANT_DIG != LDBL_MANT_DIG))) \
   && !defined(BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS)
//#  define BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS
#endif

To me, this appears to be an error.

2. Debian linux for hppa has been shipping with a patch for this condition. Specifically to exclude linux in this situation:

#if (defined(__CYGWIN__) || defined(__FreeBSD__) || defined(__NetBSD__) \
  || (defined(__hppa) && !defined(__OpenBSD__) && !defined(__linux__)) || (defined(__NO_LONG_DOUBLE_MATH) && (DBL_MANT_DIG != LDBL_MANT_DIG))) \
  && !defined(BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS)

...

UB in test_roots

To reproduce:

$  ../../../b2 -a --reconfigure cxxflags="--std=gnu++17 -fsanitize=address -fsanitize=undefined" linkflags="-fsanitize=address -fsanitize=undefined" test_roots
====== BEGIN OUTPUT ======
../../../boost/math/tools/roots.hpp:439:137: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../../boost/math/tools/roots.hpp:439:137 in
../../../boost/math/tools/roots.hpp:439:137: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../../boost/math/tools/roots.hpp:439:137 in

bracket_and_solve_root, toms748_solve; underflow when max_iter == 0

~line 295, math/tools/toms748_solve.hpp

std::pair<T, T> toms748_solve(...)

Parameter max_iter is boost::uintmax_t. Line ~343 decrements count (--count) with no prior checks on the value of max_iter, resulting in an underflow if the provided max_iter==0.

This was discovered when calling bracket_and_solve root (with max_iters==15), which internally calls toms748_solve with max_iter==0, leading to the underflow/infinite(?) loop.

Unfortunately due to the nature of bracket_and_solve root I'm unable to provide a minimal repro, but to repro the underflow simply call toms748_solve with max_iter==0, which it does not appear to be checking against.

Alternatively/additionally, bracket_and_solve root is calling toms748_solve with max_iter==0; I don't know if that is desired behavior.

Moved from : https://svn.boost.org/trac10/ticket/13129

ADL fails for `expm1`

#include <boost/math/special_functions/expm1.hpp>
// Alternatively, include:
// #include <boost/math/special_functions/math_fwd.hpp>
#include <boost/multiprecision/cpp_bin_float.hpp>


using boost::multiprecision::cpp_bin_float_50;

int main()
{
    using std::expm1;
    cpp_bin_float_50 x = 0.0000001;
    cpp_bin_float_50 y = expm1(x);
}

This yields the error:

fatal error: call to function 'expm1' that is neither visible in the template definition nor found by argument-dependent lookup
...
/include/boost/math/special_functions/expm1.hpp:318:46: note: 'expm1' should be declared prior to the call site or in an associated namespace of one of its
      arguments
inline typename tools::promote_args<T>::type expm1(T x)

`formula_format` only defined in .cpp file

In the polynomial documentation, a very nice function called formula_format is discussed. However, grepping through the project, the only place I can find the definition of this function is in example/polynomial_arithmetic.cpp, and hence I can't #include it anywhere in my own code.

This formula_format should be made a member function on the polynomial class, or a free function somewhere accessible.

Example does not compile

Quick problem I'll hopefully be able to fix soon:

https://stackoverflow.com/questions/45545709/c-continued-fraction-evaluation-using-boost-math

erf(NaN) and erfc(NaN) do not return NaN

It is expected that erf(NaN) and erfc(NaN) are NaN, but they are not:

#include <iostream>
#include <cmath>
#include "boost/math/special_functions/erf.hpp"

int main(){
    std::cout << boost::math::erf(nan("")) << "\n";
    std::cout << boost::math::erfc(nan("")) << "\n";
    return 0;
}

Output:

1
0

Moved from Trac

Can sin_pi be sped up without error?

I noticed that sin_pi seems a little slow. What I don't know is whether or not this necessary for some reason or another.

I have written the following benchmarks, and also given what I think may be a simplified implementation (but not yet checked its ULP accuracy):

#include <benchmark/benchmark.h>
#include <random>
#include <iostream>
#include <algorithm>
#include <boost/math/special_functions/sin_pi.hpp>

template<class Real>
void BM_SinPi(benchmark::State& state)
{

    std::mt19937 gen(323723);
    std::uniform_real_distribution<Real> dis(-0.95, 0.95);

    for (auto _ : state)
    {
        Real arg = dis(gen);
        benchmark::DoNotOptimize(boost::math::sin_pi(arg));
    }
}
BENCHMARK_TEMPLATE(BM_SinPi, float);
BENCHMARK_TEMPLATE(BM_SinPi, double);


template<class Real>
Real sin_pi2(Real x)
{
    using std::sin;
    using std::floor;
    using boost::math::constants::pi;
    if(x < 0) {
      return -sin_pi2(-x);
    }

    Real integer_part = floor(x);
    Real rem = x - integer_part;
    if (rem > 0.5) {
        rem = 1 - rem;
    }

    long i = static_cast<long>(integer_part);

    if (i & 1) {
        return -sin(pi<Real>()*rem);
    } else {
        return sin(pi<Real>()*rem);
    }
}

template<class Real>
void BM_SinPi2(benchmark::State& state)
{

    std::mt19937 gen(323723);
    std::uniform_real_distribution<Real> dis(-0.95, 0.95);

    for (auto _ : state)
    {
        Real arg = dis(gen);
        benchmark::DoNotOptimize(sin_pi2(arg));
    }
}
BENCHMARK_TEMPLATE(BM_SinPi2, float);
BENCHMARK_TEMPLATE(BM_SinPi2, double);

template<class Real>
void BM_Sin(benchmark::State& state)
{

    std::mt19937 gen(323723);
    std::uniform_real_distribution<Real> dis(-0.95, 0.95);

    for (auto _ : state)
    {
        Real arg = dis(gen);
        benchmark::DoNotOptimize(std::sin(arg));
    }
}
BENCHMARK_TEMPLATE(BM_Sin, float);
BENCHMARK_TEMPLATE(BM_Sin, double);

BENCHMARK_MAIN();

The performance is shown below:

BM_SinPi<float>         88.7 ns         88.6 ns      7885039
BM_SinPi<double>         141 ns          141 ns      4972259
BM_SinPi2<float>        34.0 ns         34.0 ns     20603917
BM_SinPi2<double>       48.9 ns         48.8 ns     14342610
BM_Sin<float>           12.5 ns         12.5 ns     56321679
BM_Sin<double>          35.1 ns         35.1 ns     19925642

Is it reasonable to replace the implementation or is there something fundamental I'm missing?

Assert failed in tanh_sinh for multiprecision cpp_bin_float and cpp_dec_float

This may be closely related to #108

It involves quadrature of a simple constant over range [0,1] using tanh_sinh from boost_1_68_0

Assertion `(left_min_complement * diff + a) > a' failed.

---

The code for file problem.cpp

#include <boost/math/quadrature/tanh_sinh.hpp>
#include <boost/multiprecision/cpp_bin_float.hpp> // For cpp_bin_float_50.
#include <boost/multiprecision/cpp_dec_float.hpp> // For cpp_dec_float_50.
#include

template
void integration(T b)
{
using namespace boost::multiprecision;

std::cout << "Quadrature " << std::endl;
std::cout << std::numeric_limits::digits << std::endl;
std::cout << std::numeric_limits::digits10 << std::endl;
std::cout.precision(std::numeric_limits::max_digits10);
std::cout << b << std::endl;
std::cout << log(b) << std::endl;

// Show all possibly significant decimal digits
// std::cout.precision(std::numeric_limits::digits10);
// Show all guaranteed significant decimal digits for T

boost::math::quadrature::tanh_sinh integrator;

auto f = [](T x) { return 7; };
T termination = sqrt(std::numeric_limits::epsilon());
T error;
T L1;
size_t levels;
T xlo = 0;
T xhi = 1;
T Q;

try {
Q = integrator.integrate(f,xlo,xhi,termination,&error,&L1,&levels);
}
catch (const std::exception& e)
{
std::cout <<
"\n""Message from thrown exception was:\n " << e.what() << std::endl;
}
std::cout << "Q " << Q << " " << std::endl;
std::cout << "error " << error << " " << std::endl;
std::cout << "L1 " << L1 << " " << std::endl;
std::cout << "levels " << levels << " " << std::endl;

T condition_number = L1/abs(Q);

std::cout << "condition_number " << condition_number << " " << std::endl;

}

int main()
{
boost::multiprecision::cpp_bin_float_50 two_bin50 = 2;
integration(two_bin50);
boost::multiprecision::cpp_dec_float_50 two_50 = 2;
integration(two_50);
}

The makefile

problem: problem.o
g++ problem.o -lquadmath -o problem

problem.o: problem.cpp
g++ -c -g -Wall -std=gnu++11 -I/home/dfc/boost_1_68_0 problem.cpp

---

The result of ./problem

Quadrature
168
50
2
0.69314718055994530941723212145817656807550013436025633
problem: /home/dfc/boost_1_68_0/boost/math/quadrature/tanh_sinh.hpp:170: decltype ((Real)(declval()(declval()))) boost::math::quadrature::tanh_sinh<Real, Policy>::integrate(F, Real, Real, Real, Real*, Real*, std::size_t*) [with F = integration(T) [with T = boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<50> >]::<lambda(boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<50> >)>; Real = boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<50> >; Policy = boost::math::policies::policy<boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy>; decltype ((Real)(declval()(declval()))) = boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<50> >; std::size_t = long unsigned int]: Assertion `(left_min_complement * diff + a) > a' failed.
Aborted (core dumped)

Documentation question

In the documentation at:

https://www.boost.org/doc/libs/1_69_0/libs/math/doc/html/math_toolkit/high_precision/use_multiprecision.html

I find the following text:

Define a text string which is a C++ comment with the program licence, copyright etc. You could of course, tailor this to your needs, including your copyright claim. There are versions of array provided by Boost.Array in boost::array or the C++11 std::array, but since not all platforms provide C++11 support, this program provides the Boost version as fallback.

static const char* prolog =
{
"// Use, modification and distribution are subject to the\n"
"// Boost Software License, Version 1.0.\n"
"// (See accompanying file LICENSE_1_0.txt\n"
"// or copy at ""http://www.boost.org/LICENSE_1_0.txt)\n\n"

"// Copyright ???? 2013.\n\n"

"// Use boost/array if std::array (C++11 feature) is not available.\n"
"#ifdef BOOST_NO_CXX11_HDR_ARRAY\n"
"#include <boost/array/array.hpp>\n"
"#else\n"
"#include \n"
"#endif\n\n"
};

using boost::multiprecision::cpp_dec_float_50;
using boost::math::constants::pi;
// VS 2010 (wrongly) requires these at file scope, not local scope in main.
// This program also requires -std=c++11 option to compile using Clang and GCC.

int main()
{

This seems way out of context to me.

float128 support for clang

Hello all,

I'm using clang 7 with boost 1.69.0, and noticed that there isn't float128 support in boost math, even though clang seems to support it.

The relevant file is /include/boost/math/tools/config.hpp:

#if defined(_GLIBCXX_USE_FLOAT128) && defined(BOOST_GCC) && !defined(__STRICT_ANSI__) \
   && !defined(BOOST_MATH_DISABLE_FLOAT128) || defined(BOOST_MATH_USE_FLOAT128)
//
// Only enable this when the compiler really is GCC as clang and probably 
// intel too don't support __float128 yet :-(
//
#ifndef BOOST_MATH_USE_FLOAT128
#  define BOOST_MATH_USE_FLOAT128
#endif

Which seemed to be a result of pre-float128 clang: https://svn.boost.org/trac10/ticket/8265

It looks like clang started adding support around 2015/2016: https://reviews.llvm.org/D15120, and it appears that clang has this support now:

    __float128 thing = 1e+100Q;
    thing += 45;
    thing /= 2;
    size_t sz = sizeof(thing);
    std::cout << sz << std::endl;
    std::cout << (double)thing << std::endl; // cast because I'm not hunting down gcc's quadmath.h in a small demo :-)

Would it be reasonable to change the line in /include/boost/math/tools/config.hpp to check for gcc or clang?

Quantile for skew_normal returns invalid value

Code example:

#include <boost/math/distributions/skew_normal.hpp>
#include <cstdlib>

int main()
{
  boost::math::skew_normal skew(573.39724735636185, 77.0, 4.0);
  const double x = boost::math::quantile(skew, 0.00285612015554148);
  const double y = boost::math::quantile(skew, 0.00285612015554149);
  const double z = boost::math::quantile(skew, 0.00285612015554150);
  std::printf("x=%g\n", x);
  std::printf("y=%g\n", y);
  std::printf("z=%g\n", z);
}

Result on Windows 10 + MSVC 19.16.27026.1 + Boost 1.67.0:

x=539.858
y=-inf
z=539.858

Result on Windows 10 + MSVC 19.16.27026.1 + Boost 1.69.0:

x=539.858
y=0
z=539.858

Extracting fpclassify.hpp and sign.hpp into a separate library?

At present there is a cyclic dependency between Math and LexicalCast, which it would be nice if we could break. LexicalCast only needs fpclassify.hpp and sign.hpp. If we could extract those to a new library, f.ex. boostorg/float, the cycle will be broken and it will be possible to work further towards reducing LexicalCast's dependencies.

As a side effect, this will remove the dependency on Math of Random and Spirit, which also only need fpclassify.hpp and sign.hpp.

Perhaps some other of the floating-point utility functions may also be candidates for migration; Convert, for instance, only needs round.

https://pdimov.github.io/boostdep-report/develop/math.html#reverse-dependencies

Boost.Math tests' poisoning of isnan can break standard libraries

https://github.com/boostorg/math/blob/develop/test/compile_test/poison.hpp defines a macro isnan. When I added an isnan assert into unordered_Xxx::max_load_factor, and that explodes. The standard explicitly prohibits doing this: http://eel.is/c++draft/requirements#macro.names

As a possible workaround, poison.hpp could include all standard library headers, not only math.h and cmath, if it wants to expose only its code to this.

(I have worked around this in MSVC++ for now but Boost shouldn't be doing this)

Complex Newton's method

Newton's method often works in the complex plane, but the current version of newton_raphson only supports real types. I propose adding a function complex_newton which works for complex types. I have tested that the following code works reasonably well:

template<class Complex, class F>
Complex complex_newton(F g, Complex guess,  size_t iterations=30)
{
    typedef typename Complex::value_type Real;
    Complex xn = guess;

    Complex f;
    Complex df;
    do {

       auto pair = g(xn);
       f = pair.first;
       df = pair.second;

       --iterations;

       xn = xn  - (f/df);
       if (abs(f) < sqrt(std::numeric_limits<Real>::epsilon()))
       {
          return xn;
       }

    } while(iterations);

    if (abs(f) > std::numeric_limits<typename Complex::value_type>::epsilon())
    {
        return {std::numeric_limits<typename Complex::value_type>::quiet_NaN(), std::numeric_limits<typename Complex::value_type>::quiet_NaN()};
    }
    return xn;
}

For instance, it recovers all the symlet and Daubechies coefficients via Maehly's procedure. However, it's not quite ready for primetime since it doesn't handle zero derivatives.

Gamma distribution CDF gives NaN for extreme value

Hello,

For some parameterisations of boost::math::gamma_distribution, the boost::math::cdf accessor fails on large values. Ideally when called with a very large finite (or indeed infinite) value, the cdf for a gamma distribution should evaluate to 1 (almost) regardless of the shape and scale parameters, but it fails for some parameterisations as illustrated by the following code.

#include <iostream>
#include <boost/version.hpp>
#include <boost/math/distributions/beta.hpp>
#include <boost/math/distributions/normal.hpp>
#include <boost/math/distributions/gamma.hpp>

int main()
{
    using namespace boost::math;

    std::cout << BOOST_VERSION << "\n";

    // Context: the CDF at the maximum value of a beta distribution evaluates to 1.
    auto beta_dist = beta_distribution<double>(3, 0.4);
    double beta_max = range(beta_dist).second;
    std::cout << "upper bound for Beta(3, 0.4) distribution is " << beta_max << ", cdf at u.b. is " << cdf(beta_dist, beta_max) << "\n";

    // Context: also works for the normal distribution.
    auto normal_dist = normal_distribution<double>(12, 0.4);
    double normal_max = range(normal_dist).second;
    std::cout << "upper bound for Normal(12, 0.4) distribution is " << normal_max << ", cdf at u.b. is " << cdf(normal_dist, normal_max) << "\n";

    // Context: works for the gamma distribution when shape = 1 and scale = 1.
    auto gamma_dist = gamma_distribution<double>(1, 1);
    double gamma_max = range(gamma_dist).second;
    std::cout << "upper bound for Gamma(1, 1) distribution is " << gamma_max << ", cdf at u.b. is " << cdf(gamma_dist, gamma_max) << "\n";

    // MINIMUM EXAMPLE OF BUG IS HERE
    // Issue: gives NaN for the gamma distribution when shape = 5 and scale = 0.35.
    auto gamma_dist2 = gamma_distribution<double>(5, 0.35);
    double gamma_max2 = range(gamma_dist2).second;
    std::cout << "upper bound for Gamma(5, 0.35) distribution is " << gamma_max2 << ", cdf at u.b. is " << cdf(gamma_dist2, gamma_max2) << "\n";

    return 0;
}

Output (GCC 8.2.0):

106800
upper bound for Beta(3, 0.4) distribution is 1, cdf at u.b. is 1
upper bound for Normal(12, 0.4) distribution is inf, cdf at u.b. is 1
upper bound for Gamma(1, 1) distribution is 1.79769e+308, cdf at u.b. is 1
upper bound for Gamma(5, 0.35) distribution is 1.79769e+308, cdf at u.b. is nan

I appreciate that this may seem like an extreme use case, but it would be helpful if the Boost distributions were consistent as illustrated by the "context" uses above. It is sometimes useful to fall back on extreme values of distributions when limits for random variables are not supplied by the user, and in this case it would be handy if the CDF gave the right values.

A related issue is that the documentation states for the gamma distribution that "The domain of the random variable is [0,+∞]"—note the upper bound which includes infinity—but the cdf function throws an exception when called with std::numeric_limits::infinity(), besides failing on finite large values as mentioned above. The normal distribution CDF works fine with infinity, so this was unexpected.

Thanks for a very useful library and best wishes,

Nick

[EDIT: Fixed typo in one of the "Context" code examples above] [EDIT2: typos/clarification]

math_fwd.hpp breaks quaternion and octonian

#include <boost/math_fwd.hpp>
#include <boost/math/quaternion.hpp>

int main() { boost::math::quaternion<double> x; }

test.cpp(4): error C2079: 'x' uses undefined class 'boost::math::quaternion'

Heap buffer overflow in Polynomial:

Code to reproduce:

#include <iostream>
#include <vector>
#include <boost/math/tools/polynomial.hpp>

using boost::math::tools::polynomial;

template<class Real>
void problem(size_t N)
{
    std::vector<Real> coeffs(N);
    for (size_t i = 0; i < coeffs.size(); ++i) {
      coeffs[i] = i;
    }

    polynomial<Real> p(coeffs.data(), coeffs.size());

    std::cout << "Polynomial: " << p << std::endl;
}

int main()
{
    problem<double>(2);
}

Compile with AddressSanitizer:

$ clang++ --std=gnu++17 -O0 -g -fsanitize=address -fsanitize=undefined -Wall -Wfatal-errors -march=native main.cpp

Then:

=================================================================
==90840==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000120 at pc 0x00010b72a581 bp 0x7ffee44eef90 sp 0x7ffee44eef88
READ of size 8 at 0x602000000120 thread T0
    #0 0x10b72a580 in std::__1::enable_if<__is_forward_iterator<double const*>::value, void>::type std::__1::vector<double, std::__1::allocator<double> >::__construct_at_end<double const*>(double const*, double const*, unsigned long) vector:1030
    #1 0x10b729a4d in std::__1::vector<double, std::__1::allocator<double> >::vector<double const*>(double const*, std::__1::enable_if<(__is_forward_iterator<double const*>::value) && (is_constructible<double, std::__1::iterator_traits<double const*>::reference>::value), double const*>::type) vector:1178
    #2 0x10b726644 in std::__1::vector<double, std::__1::allocator<double> >::vector<double const*>(double const*, std::__1::enable_if<(__is_forward_iterator<double const*>::value) && (is_constructible<double, std::__1::iterator_traits<double const*>::reference>::value), double const*>::type) vector:1170
    #3 0x10b72656d in boost::math::tools::polynomial<double>::polynomial<double>(double const*, unsigned int) polynomial.hpp:292
    #4 0x10b71e300 in boost::math::tools::polynomial<double>::polynomial<double>(double const*, unsigned int) polynomial.hpp:293
    #5 0x10b711c00 in void problem<double>(unsigned long) main.cpp:21
    #6 0x10b7114b7 in main main.cpp:28
    #7 0x7fff6fc2b08c in start (libdyld.dylib:x86_64+0x1708c)

The constructor call should be polynomial<double> p(coeffs.data(), coeffs.size() -1), but this doesn't seem idiomatic to me. Is there any way we can assert on this?

Add move constructor for barycentric_rational

I'll check this one off hopefully soon . . .

integer overflow (UBSAN)

Build environment: boostorg/boost#184 (docker)

boost@a7d451ec0735:/boost/libs/math/test$ UBSAN_OPTIONS=print_stacktrace=1 ../../../b2 toolset=gcc-7 cxxstd=03 cxxflags=-fno-omit-frame-pointer cxxflags=-fsanitize=undefined cxxflags=-fno-sanitize-recover=undefined linkflags=-fsanitize=undefined linkflags=-fno-sanitize-recover=undefined linkflags=-fuse-ld=gold variant=debug -q -a

...

testing.capture-output ../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.run
====== BEGIN OUTPUT ======
Running 1 test case...
Testing type cpp_dec_float_50
Denormals are flushed to zero.
Testing type cpp_dec_float_50 with initial value 1.34567e+22
Testing type cpp_dec_float_50 with initial value -1.34567e+22
Testing type cpp_dec_float_50 with initial value 1.34567e-22
Testing type cpp_dec_float_50 with initial value -1.34567e-22
Testing type cpp_dec_float_50 with initial value 4.48557e-23
Testing type cpp_dec_float_50 with initial value -4.48557e-23
Testing type cpp_dec_float_50 with initial value 1e-49
Testing type cpp_dec_float_50 with initial value -1e-49
Testing type cpp_dec_float_50 with initial value 1e-67108864
../../../boost/math/special_functions/next.hpp:76:72: runtime error: signed integer overflow: 49 - -2147483648 cannot be represented in type 'int'
    #0 0x557eb0c2c6ba in boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> boost::math::detail::normalize_value<boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> >(boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> const&, mpl_::bool_<true> const&) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x1db6ba)
    #1 0x557eb0c2e0e3 in boost::math::tools::promote_args<boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1>, boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1>, float, float, float, float>::type boost::math::float_distance<boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1>, boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1>, boost::math::policies::policy<boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >(boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> const&, boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> const&, boost::math::policies::policy<boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> const&) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x1dd0e3)
    #2 0x557eb0c32da4 in void test_value<boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> >(boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> const&, char const*) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x1e1da4)
    #3 0x557eb0c3960e in void test_values<boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> >(boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<50u, int, void>, (boost::multiprecision::expression_template_option)1> const&, char const*) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x1e860e)
    #4 0x557eb0bf36f1 in test_main_invoker() (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x1a26f1)
    #5 0x557eb0d9298b in boost::detail::function::function_obj_invoker0<boost::detail::forward, int>::invoke(boost::detail::function::function_buffer&) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x34198b)
    #6 0x557eb0d90084 in boost::execution_monitor::catch_signals(boost::function<int ()> const&) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x33f084)
    #7 0x557eb0d9043a in boost::execution_monitor::execute(boost::function<int ()> const&) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x33f43a)
    #8 0x557eb0d921d9 in boost::execution_monitor::vexecute(boost::function<void ()> const&) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x3411d9)
    #9 0x557eb0d81e15 in boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::function<void ()> const&, unsigned int) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x330e15)
    #10 0x557eb0d67ef1 in boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned int, boost::unit_test::framework::state::random_generator_helper const*) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x316ef1)
    #11 0x557eb0d68952 in boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned int, boost::unit_test::framework::state::random_generator_helper const*) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x317952)
    #12 0x557eb0d505f2 in boost::unit_test::framework::run(unsigned long, bool) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x2ff5f2)
    #13 0x557eb0c9d23b in boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**) (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x24c23b)
    #14 0x7f796e36eb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #15 0x557eb0bf15d9 in _start (/boost/bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal+0x1a05d9)


EXIT STATUS: 1
====== END OUTPUT ======

    LD_LIBRARY_PATH="/usr/bin:/usr/lib:/usr/lib32:/usr/lib64:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH

    status=0
    if test $status -ne 0 ; then
        echo Skipping test execution due to testing.execute=off
        exit 0
    fi
     "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal"   > "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.output" 2>&1 < /dev/null
    status=$?
    echo >> "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.output"
    echo EXIT STATUS: $status >> "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.output"
    if test $status -eq 0 ; then
        cp "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.output" "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.run"
    fi
    verbose=0
    if test $status -ne 0 ; then
        verbose=1
    fi
    if test $verbose -eq 1 ; then
        echo ====== BEGIN OUTPUT ======
        cat "../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.output"
        echo ====== END OUTPUT ======
    fi
    exit $status

...failed testing.capture-output ../../../bin.v2/libs/math/test/test_next_decimal.test/gcc-7/release/cxxstd-03-iso/link-static/test_next_decimal.run...
...failed updating 1 target...
...skipped 1 target...
...updated 973 targets...

Excessive warnings with gcc-7 build (warning: floating constant truncated to zero [-Woverflow])

Build environment: boostorg/boost#184 (docker)

boost@a7d451ec0735:/boost/libs/math/test$ UBSAN_OPTIONS=print_stacktrace=1 ../../../b2 toolset=gcc-7 cxxstd=03 cxxflags=-fno-omit-frame-pointer cxxflags=-fsanitize=undefined cxxflags=-fno-sanitize-recover=undefined linkflags=-fsanitize=undefined linkflags=-fno-sanitize-recover=undefined linkflags=-fuse-ld=gold variant=debug -q -a

...

gcc.compile.c++ ../../../bin.v2/libs/math/test/test_ibeta_derivative_float.test/gcc-7/debug/cxxstd-03-iso/link-static/test_ibeta_derivative.o
In file included from test_ibeta_derivative.hpp:104:0,
                 from test_ibeta_derivative.cpp:7:
ibeta_derivative_large_data.ipp:8:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.0476082934474106878042221069335937500000e-05), SC_(3.9078187500000000000000000000000000000000e+04), SC_(9.1338449716567993164062500000000000000000e-01), SC_(1.9269302505055971245108533005908825520385e-41521) }},
 ^
In file included from test_ibeta_derivative.hpp:104:0,
                 from test_ibeta_derivative.cpp:7:
ibeta_derivative_large_data.ipp:19:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.5196248568827286362648010253906250000000e-05), SC_(1.6177537109375000000000000000000000000000e+04), SC_(8.1474220752716064453125000000000000000000e-01), SC_(2.6910083770664820015271856038619503004517e-11850) }},
 ^
ibeta_derivative_large_data.ipp:24:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.6487292668898589909076690673828125000000e-05), SC_(4.7099715625000000000000000000000000000000e+05), SC_(1.2707412242889404296875000000000000000000e-01), SC_(4.7913621881963152427739710649393818331186e-27804) }},
 ^
ibeta_derivative_large_data.ipp:26:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.6625948774162679910659790039062500000000e-05), SC_(1.4781887500000000000000000000000000000000e+05), SC_(6.3239604234695434570312500000000000000000e-01), SC_(6.9409752645519688050551102031654135482280e-64250) }},
 ^
ibeta_derivative_large_data.ipp:36:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.0518851670203730463981628417968750000000e-05), SC_(2.3608789062500000000000000000000000000000e+05), SC_(8.3502507209777832031250000000000000000000e-01), SC_(1.0643188085559563702319912328927622466179e-184762) }},
 ^
ibeta_derivative_large_data.ipp:41:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.2448601157520897686481475830078125000000e-05), SC_(4.4507128125000000000000000000000000000000e+05), SC_(2.2111195325851440429687500000000000000000e-01), SC_(5.9123809355675617071100882089078885260769e-48306) }},
 ^
ibeta_derivative_large_data.ipp:43:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.3484906705562025308609008789062500000000e-05), SC_(2.5542792968750000000000000000000000000000e+04), SC_(9.6887087821960449218750000000000000000000e-01), SC_(1.4613292200324103655664350909547841376771e-38492) }},
 ^
ibeta_derivative_large_data.ipp:53:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.8775624741683714091777801513671875000000e-05), SC_(2.5491835937500000000000000000000000000000e+04), SC_(9.0580135583877563476562500000000000000000e-01), SC_(1.1032298987116139029535922026525897628421e-26157) }},
 ^
ibeta_derivative_large_data.ipp:59:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.1141327781369909644126892089843750000000e-05), SC_(3.4814400000000000000000000000000000000000e+05), SC_(3.0823621153831481933593750000000000000000e-01), SC_(2.7636151215428645239088811782828970918951e-55722) }},
 ^
ibeta_derivative_large_data.ipp:65:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.2752945116953924298286437988281250000000e-05), SC_(2.5796328125000000000000000000000000000000e+04), SC_(8.3502507209777832031250000000000000000000e-01), SC_(4.2940316248959287719701453977114063200351e-20192) }},
 ^
ibeta_derivative_large_data.ipp:68:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.4079275792464613914489746093750000000000e-05), SC_(2.8878271875000000000000000000000000000000e+05), SC_(8.1474220752716064453125000000000000000000e-01), SC_(7.1846471146087755187409010904609987781251e-211458) }},
 ^
ibeta_derivative_large_data.ipp:72:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.6163164622848853468894958496093750000000e-05), SC_(3.1193678125000000000000000000000000000000e+05), SC_(9.0580135583877563476562500000000000000000e-01), SC_(2.6205419590313223140339713942080040984787e-320037) }},
 ^
ibeta_derivative_large_data.ipp:78:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.7568581319646909832954406738281250000000e-05), SC_(3.8644028125000000000000000000000000000000e+05), SC_(9.1338449716567993164062500000000000000000e-01), SC_(6.8174519857164532475052618081523822045041e-410560) }},
 ^
ibeta_derivative_large_data.ipp:84:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.9926064346218481659889221191406250000000e-05), SC_(4.9535178125000000000000000000000000000000e+05), SC_(9.6887087821960449218750000000000000000000e-01), SC_(4.4290617776725095490336667453265158011523e-746416) }},
 ^
ibeta_derivative_large_data.ipp:93:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.1771381802391260862350463867187500000000e-05), SC_(2.7444700000000000000000000000000000000000e+05), SC_(1.3556346297264099121093750000000000000000e-01), SC_(1.3975926421252055322670197081515642386213e-17367) }},
 ^
ibeta_derivative_large_data.ipp:109:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.7360430471599102020263671875000000000000e-05), SC_(4.8598652343750000000000000000000000000000e+04), SC_(6.3239604234695434570312500000000000000000e-01), SC_(2.3531980913981155127652388143121372265904e-21126) }},
 ^
ibeta_derivative_large_data.ipp:138:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.6828322259243577718734741210937500000000e-04), SC_(1.9580098437500000000000000000000000000000e+05), SC_(9.0580135583877563476562500000000000000000e-01), SC_(1.6935529145462839421446512394795950820774e-200886) }},
 ^
ibeta_derivative_large_data.ipp:143:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.7790572019293904304504394531250000000000e-04), SC_(2.7648940625000000000000000000000000000000e+05), SC_(8.1474220752716064453125000000000000000000e-01), SC_(1.0651325009895042591469758624823221627316e-202455) }},
 ^
ibeta_derivative_large_data.ipp:144:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.8309691222384572029113769531250000000000e-04), SC_(3.1605518750000000000000000000000000000000e+05), SC_(1.2707412242889404296875000000000000000000e-01), SC_(6.4501626999469717477687108215153398543674e-18658) }},
 ^
ibeta_derivative_large_data.ipp:145:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.9036870799027383327484130859375000000000e-04), SC_(1.5913159375000000000000000000000000000000e+05), SC_(8.3502507209777832031250000000000000000000e-01), SC_(4.0945383165983151190759951524057154854408e-124537) }},
 ^
ibeta_derivative_large_data.ipp:146:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.9106571562588214874267578125000000000000e-04), SC_(4.1986128125000000000000000000000000000000e+05), SC_(9.1338449716567993164062500000000000000000e-01), SC_(8.4034851252163134328342054094486879586776e-446066) }},
 ^
ibeta_derivative_large_data.ipp:148:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.9219527894165366888046264648437500000000e-04), SC_(1.7779815625000000000000000000000000000000e+05), SC_(3.0823621153831481933593750000000000000000e-01), SC_(5.6508791678068131434383641180273083066262e-28459) }},
 ^
ibeta_derivative_large_data.ipp:156:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.2049853578209877014160156250000000000000e-04), SC_(1.0738034375000000000000000000000000000000e+05), SC_(1.3556346297264099121093750000000000000000e-01), SC_(4.5251154920704647877712378961863260052437e-6797) }},
 ^
ibeta_derivative_large_data.ipp:159:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.4029082851484417915344238281250000000000e-04), SC_(4.9604398437500000000000000000000000000000e+04), SC_(6.3239604234695434570312500000000000000000e-01), SC_(9.1349982054617270986331708242468562525438e-21563) }},
 ^
ibeta_derivative_large_data.ipp:171:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.7427947497926652431488037109375000000000e-04), SC_(2.8920603125000000000000000000000000000000e+05), SC_(9.6887087821960449218750000000000000000000e-01), SC_(5.3777204674313794449821915190465508644271e-435788) }},
 ^
ibeta_derivative_large_data.ipp:177:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.8836930869147181510925292968750000000000e-04), SC_(4.6007328125000000000000000000000000000000e+05), SC_(2.2111195325851440429687500000000000000000e-01), SC_(6.1724159772800828969078529404963347872813e-49933) }},
 ^
ibeta_derivative_large_data.ipp:184:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.1313023646362125873565673828125000000000e-04), SC_(4.7957000000000000000000000000000000000000e+04), SC_(3.0823621153831481933593750000000000000000e-01), SC_(1.0608459926080077951610595482549956912153e-7678) }},
 ^
ibeta_derivative_large_data.ipp:188:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.2006253604777157306671142578125000000000e-04), SC_(2.5544605468750000000000000000000000000000e+04), SC_(9.0580135583877563476562500000000000000000e-01), SC_(8.9338278494735889152345055758304626213553e-26211) }},
 ^
ibeta_derivative_large_data.ipp:191:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.3481788705103099346160888671875000000000e-04), SC_(2.9065523437500000000000000000000000000000e+04), SC_(9.6887087821960449218750000000000000000000e-01), SC_(1.4231437416199713795072604511704202471692e-43799) }},
 ^
ibeta_derivative_large_data.ipp:193:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.4899002639576792716979980468750000000000e-04), SC_(4.1187574218750000000000000000000000000000e+04), SC_(9.1338449716567993164062500000000000000000e-01), SC_(6.1298238383770060757160024427497924559871e-43761) }},
 ^
ibeta_derivative_large_data.ipp:205:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.1793254786171019077301025390625000000000e-04), SC_(4.6684711914062500000000000000000000000000e+03), SC_(9.6887087821960449218750000000000000000000e-01), SC_(3.4374868335419786925808844366787929641791e-7037) }},
 ^
ibeta_derivative_large_data.ipp:212:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.3772353092208504676818847656250000000000e-04), SC_(4.5439925000000000000000000000000000000000e+05), SC_(6.3239604234695434570312500000000000000000e-01), SC_(2.2717145184729847073889335573392399775587e-197494) }},
 ^
ibeta_derivative_large_data.ipp:216:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.5037711970508098602294921875000000000000e-04), SC_(1.0660823242187500000000000000000000000000e+04), SC_(8.3502507209777832031250000000000000000000e-01), SC_(3.5270647184255903946452023089697983264030e-8346) }},
 ^
ibeta_derivative_large_data.ipp:222:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.7560062375850975513458251953125000000000e-04), SC_(1.9603037109375000000000000000000000000000e+04), SC_(8.1474220752716064453125000000000000000000e-01), SC_(4.9638798961863947019744238416273701503378e-14357) }},
 ^
ibeta_derivative_large_data.ipp:234:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.2418846599757671356201171875000000000000e-03), SC_(2.1106562500000000000000000000000000000000e+05), SC_(6.3239604234695434570312500000000000000000e-01), SC_(2.6921662958050124797307339272689183630517e-91736) }},
 ^
ibeta_derivative_large_data.ipp:236:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.3338791904971003532409667968750000000000e-03), SC_(4.6277761718750000000000000000000000000000e+04), SC_(9.1338449716567993164062500000000000000000e-01), SC_(3.4445488427585501086621205522098573758876e-49168) }},
 ^
ibeta_derivative_large_data.ipp:243:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.5326840803027153015136718750000000000000e-03), SC_(1.3060160156250000000000000000000000000000e+04), SC_(9.6887087821960449218750000000000000000000e-01), SC_(1.7008426159810406172458099034634845255558e-19681) }},
 ^
ibeta_derivative_large_data.ipp:247:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.6935544554144144058227539062500000000000e-03), SC_(3.8556156250000000000000000000000000000000e+05), SC_(1.2707412242889404296875000000000000000000e-01), SC_(2.1576757512113325950348333158100592470559e-22759) }},
 ^
ibeta_derivative_large_data.ipp:265:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.5637513026595115661621093750000000000000e-03), SC_(3.4688196875000000000000000000000000000000e+05), SC_(1.3556346297264099121093750000000000000000e-01), SC_(1.6253534868826310969249464175570424442994e-21948) }},
 ^
ibeta_derivative_large_data.ipp:267:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.5970311835408210754394531250000000000000e-03), SC_(4.4323968750000000000000000000000000000000e+05), SC_(8.1474220752716064453125000000000000000000e-01), SC_(5.3538058059701126122070972352638462688337e-324553) }},
 ^
ibeta_derivative_large_data.ipp:269:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.6671977248042821884155273437500000000000e-03), SC_(3.4691165625000000000000000000000000000000e+05), SC_(9.0580135583877563476562500000000000000000e-01), SC_(4.3776939036313978467122830615443127468115e-355918) }},
 ^
ibeta_derivative_large_data.ipp:272:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.7295660693198442459106445312500000000000e-03), SC_(1.9772785156250000000000000000000000000000e+04), SC_(8.3502507209777832031250000000000000000000e-01), SC_(3.0365048601767829339883410426267334895674e-15476) }},
 ^
ibeta_derivative_large_data.ipp:274:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.8151907026767730712890625000000000000000e-03), SC_(2.7477316406250000000000000000000000000000e+04), SC_(8.1474220752716064453125000000000000000000e-01), SC_(5.5776360210863456846948942066750127630285e-20122) }},
 ^
ibeta_derivative_large_data.ipp:288:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.1075035221874713897705078125000000000000e-03), SC_(4.6357459375000000000000000000000000000000e+05), SC_(8.3502507209777832031250000000000000000000e-01), SC_(1.6377535510420021404970569155481010138464e-362787) }},
 ^
ibeta_derivative_large_data.ipp:297:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.5118935629725456237792968750000000000000e-03), SC_(3.0600946875000000000000000000000000000000e+05), SC_(9.6887087821960449218750000000000000000000e-01), SC_(7.5880099782618915225036041363398497042732e-461107) }},
 ^
ibeta_derivative_large_data.ipp:298:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.5959659144282341003417968750000000000000e-03), SC_(3.5727242187500000000000000000000000000000e+04), SC_(3.0823621153831481933593750000000000000000e-01), SC_(2.3814279395792897382064202127386045672482e-5720) }},
 ^
ibeta_derivative_large_data.ipp:300:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.6274394951760768890380859375000000000000e-03), SC_(1.7232748437500000000000000000000000000000e+05), SC_(9.1338449716567993164062500000000000000000e-01), SC_(1.6173443475569842733657281503741625774623e-183083) }},
 ^
ibeta_derivative_large_data.ipp:315:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.2013223282992839813232421875000000000000e-03), SC_(2.8909285156250000000000000000000000000000e+04), SC_(6.3239604234695434570312500000000000000000e-01), SC_(5.3408717554349644586270159619478930393395e-12567) }},
 ^
ibeta_derivative_large_data.ipp:317:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.2134574614465236663818359375000000000000e-03), SC_(2.5879273437500000000000000000000000000000e+05), SC_(3.0823621153831481933593750000000000000000e-01), SC_(3.6750353364106837565378624549986468234093e-41420) }},
 ^
ibeta_derivative_large_data.ipp:321:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.3012551032006740570068359375000000000000e-03), SC_(3.0236775390625000000000000000000000000000e+04), SC_(9.0580135583877563476562500000000000000000e-01), SC_(1.3843755051242184364052956520728526255447e-31023) }},
 ^
ibeta_derivative_large_data.ipp:322:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.3255193158984184265136718750000000000000e-03), SC_(1.7563367187500000000000000000000000000000e+05), SC_(2.2111195325851440429687500000000000000000e-01), SC_(6.0741008774035756147180601071836490561972e-19063) }},
 ^
ibeta_derivative_large_data.ipp:343:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.2719709426164627075195312500000000000000e-02), SC_(4.6178993750000000000000000000000000000000e+05), SC_(9.6887087821960449218750000000000000000000e-01), SC_(2.1009697542642831952102526356542305762626e-695841) }},
 ^
ibeta_derivative_large_data.ipp:352:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.6146268695592880249023437500000000000000e-02), SC_(3.1081712890625000000000000000000000000000e+04), SC_(6.3239604234695434570312500000000000000000e-01), SC_(1.5362783124682873210856902037619866885897e-13510) }},
 ^
ibeta_derivative_large_data.ipp:363:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.9628280773758888244628906250000000000000e-02), SC_(2.6630503125000000000000000000000000000000e+05), SC_(6.3239604234695434570312500000000000000000e-01), SC_(3.8788711458778569572974184004227092106284e-115743) }},
 ^
ibeta_derivative_large_data.ipp:369:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.1240210160613059997558593750000000000000e-02), SC_(2.0481953125000000000000000000000000000000e+04), SC_(8.1474220752716064453125000000000000000000e-01), SC_(7.5074783480694195224773769182605035050887e-14999) }},
 ^
ibeta_derivative_large_data.ipp:370:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.1562583744525909423828125000000000000000e-02), SC_(1.2217657812500000000000000000000000000000e+05), SC_(8.3502507209777832031250000000000000000000e-01), SC_(1.2897810464099723689100073991273216793707e-95614) }},
 ^
ibeta_derivative_large_data.ipp:391:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.7603406459093093872070312500000000000000e-02), SC_(2.9335007812500000000000000000000000000000e+04), SC_(8.3502507209777832031250000000000000000000e-01), SC_(2.3934156552902576720665200232905168132515e-22958) }},
 ^
ibeta_derivative_large_data.ipp:392:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.8296975418925285339355468750000000000000e-02), SC_(1.3777629882812500000000000000000000000000e+04), SC_(9.1338449716567993164062500000000000000000e-01), SC_(1.8286558891197193698642142940986205725550e-14638) }},
 ^
ibeta_derivative_large_data.ipp:397:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.0722083523869514465332031250000000000000e-02), SC_(4.8793487500000000000000000000000000000000e+05), SC_(1.2707412242889404296875000000000000000000e-01), SC_(2.4919666626127900860665974246525223484549e-28800) }},
 ^
ibeta_derivative_large_data.ipp:398:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.1085710972547531127929687500000000000000e-02), SC_(1.5232218750000000000000000000000000000000e+04), SC_(9.0580135583877563476562500000000000000000e-01), SC_(1.3223100215231888519416678792829795837035e-15628) }},
 ^
ibeta_derivative_large_data.ipp:411:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.5508364439010620117187500000000000000000e-02), SC_(2.0727054687500000000000000000000000000000e+05), SC_(2.2111195325851440429687500000000000000000e-01), SC_(2.8852771073826825330445929164138614338264e-22495) }},
 ^
ibeta_derivative_large_data.ipp:418:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.6872327327728271484375000000000000000000e-02), SC_(3.4549765625000000000000000000000000000000e+05), SC_(9.0580135583877563476562500000000000000000e-01), SC_(4.7733337436617286800127634939955048499829e-354466) }},
 ^
ibeta_derivative_large_data.ipp:419:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.7044893950223922729492187500000000000000e-02), SC_(2.8988734375000000000000000000000000000000e+05), SC_(8.1474220752716064453125000000000000000000e-01), SC_(1.8531373264673361045739530183974554277199e-212263) }},
 ^
ibeta_derivative_large_data.ipp:420:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.7805620580911636352539062500000000000000e-02), SC_(2.9624768750000000000000000000000000000000e+05), SC_(9.1338449716567993164062500000000000000000e-01), SC_(1.1379889721758465720301599144818339146513e-314735) }},
 ^
ibeta_derivative_large_data.ipp:433:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.5014861971139907836914062500000000000000e-02), SC_(1.4815267578125000000000000000000000000000e+04), SC_(9.6887087821960449218750000000000000000000e-01), SC_(1.7202241349105880078969429760245964298823e-22324) }},
 ^
ibeta_derivative_large_data.ipp:439:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.7744903713464736938476562500000000000000e-02), SC_(4.0251265625000000000000000000000000000000e+05), SC_(1.3556346297264099121093750000000000000000e-01), SC_(1.3347526569583289529540625545737073174007e-25466) }},
 ^
ibeta_derivative_large_data.ipp:441:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.8307757824659347534179687500000000000000e-02), SC_(3.8996237500000000000000000000000000000000e+05), SC_(3.0823621153831481933593750000000000000000e-01), SC_(1.5309884068930981624246111121632455529637e-62411) }},
 ^
ibeta_derivative_large_data.ipp:451:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.1778163909912109375000000000000000000000e-01), SC_(2.0635500000000000000000000000000000000000e+05), SC_(6.3239604234695434570312500000000000000000e-01), SC_(2.2844291772680370317083639165000816020257e-89686) }},
 ^
ibeta_derivative_large_data.ipp:459:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.5554967522621154785156250000000000000000e-01), SC_(4.9261616210937500000000000000000000000000e+03), SC_(9.6887087821960449218750000000000000000000e-01), SC_(2.5826474847560445698643263250270941188505e-7422) }},
 ^
ibeta_derivative_large_data.ipp:460:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.5999889373779296875000000000000000000000e-01), SC_(3.4621112500000000000000000000000000000000e+05), SC_(1.3556346297264099121093750000000000000000e-01), SC_(1.6398546929238207971301655521446151910948e-21903) }},
 ^
ibeta_derivative_large_data.ipp:470:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.9711413979530334472656250000000000000000e-01), SC_(1.4735862500000000000000000000000000000000e+05), SC_(8.3502507209777832031250000000000000000000e-01), SC_(9.5585950812567551211581015868154946750779e-115320) }},
 ^
ibeta_derivative_large_data.ipp:474:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.0485810935497283935546875000000000000000e-01), SC_(4.8050575000000000000000000000000000000000e+05), SC_(3.0823621153831481933593750000000000000000e-01), SC_(7.8326586835231902752880607620368667842729e-76901) }},
 ^
ibeta_derivative_large_data.ipp:482:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.3908504843711853027343750000000000000000e-01), SC_(3.9427212500000000000000000000000000000000e+05), SC_(1.2707412242889404296875000000000000000000e-01), SC_(3.3134750421477624459652477332385611774019e-23270) }},
 ^
ibeta_derivative_large_data.ipp:484:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.4369129538536071777343750000000000000000e-01), SC_(1.9345748437500000000000000000000000000000e+05), SC_(9.6887087821960449218750000000000000000000e-01), SC_(1.2229314579982108574476096506416609420204e-291506) }},
 ^
ibeta_derivative_large_data.ipp:487:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.5738254189491271972656250000000000000000e-01), SC_(4.4778414062500000000000000000000000000000e+04), SC_(8.3502507209777832031250000000000000000000e-01), SC_(5.1122134403147667485731779986571509131027e-35042) }},
 ^
ibeta_derivative_large_data.ipp:492:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.7696090936660766601562500000000000000000e-01), SC_(2.2522628125000000000000000000000000000000e+05), SC_(9.0580135583877563476562500000000000000000e-01), SC_(8.3037152108950621766081905285268498572607e-231071) }},
 ^
ibeta_derivative_large_data.ipp:501:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(2.9394131898880004882812500000000000000000e-01), SC_(4.3703574218750000000000000000000000000000e+04), SC_(8.1474220752716064453125000000000000000000e-01), SC_(7.7468969583453505953814594003217678964229e-32000) }},
 ^
ibeta_derivative_large_data.ipp:502:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.0802100896835327148437500000000000000000e-01), SC_(3.4557273437500000000000000000000000000000e+04), SC_(9.6887087821960449218750000000000000000000e-01), SC_(2.5461486054507120150629540155813778104181e-52070) }},
 ^
ibeta_derivative_large_data.ipp:512:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.3443683385848999023437500000000000000000e-01), SC_(3.6505203125000000000000000000000000000000e+05), SC_(2.2111195325851440429687500000000000000000e-01), SC_(5.2607784732120216003510374999848437780676e-39616) }},
 ^
ibeta_derivative_large_data.ipp:527:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.6857244372367858886718750000000000000000e-01), SC_(1.3019937500000000000000000000000000000000e+04), SC_(9.0580135583877563476562500000000000000000e-01), SC_(2.0535867944288109485568197409909987737394e-13356) }},
 ^
ibeta_derivative_large_data.ipp:531:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.7511843442916870117187500000000000000000e-01), SC_(4.4884615625000000000000000000000000000000e+05), SC_(9.1338449716567993164062500000000000000000e-01), SC_(5.1890236012059698586471286181976379614638e-476854) }},
 ^
ibeta_derivative_large_data.ipp:537:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(3.9650318026542663574218750000000000000000e-01), SC_(1.1295042968750000000000000000000000000000e+04), SC_(9.1338449716567993164062500000000000000000e-01), SC_(2.7556726404591589517513825833916053164984e-11998) }},
 ^
ibeta_derivative_large_data.ipp:538:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.0197330713272094726562500000000000000000e-01), SC_(4.6775428125000000000000000000000000000000e+05), SC_(8.1474220752716064453125000000000000000000e-01), SC_(1.0882185128372429800839093569740443380433e-342498) }},
 ^
ibeta_derivative_large_data.ipp:549:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.4445592164993286132812500000000000000000e-01), SC_(4.9022464843750000000000000000000000000000e+04), SC_(6.3239604234695434570312500000000000000000e-01), SC_(1.5683888441437877556482661153394843725052e-21304) }},
 ^
ibeta_derivative_large_data.ipp:562:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.1706095933914184570312500000000000000000e+00), SC_(3.7448643750000000000000000000000000000000e+05), SC_(2.2111195325851440429687500000000000000000e-01), SC_(2.6800054210597822025114229462546405539356e-40635) }},
 ^
ibeta_derivative_large_data.ipp:563:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.1981303691864013671875000000000000000000e+00), SC_(1.8840236328125000000000000000000000000000e+04), SC_(8.1474220752716064453125000000000000000000e-01), SC_(4.0688913519008779017094956797722408702163e-13790) }},
 ^
ibeta_derivative_large_data.ipp:569:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.4923349618911743164062500000000000000000e+00), SC_(4.7973695312500000000000000000000000000000e+04), SC_(9.1338449716567993164062500000000000000000e-01), SC_(4.1469289808231367573381463286047486594464e-50960) }},
 ^
ibeta_derivative_large_data.ipp:571:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.5860595703125000000000000000000000000000e+00), SC_(2.6834143750000000000000000000000000000000e+05), SC_(1.2707412242889404296875000000000000000000e-01), SC_(9.4608114963011865123228306369584390935473e-15831) }},
 ^
ibeta_derivative_large_data.ipp:575:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.7562887668609619140625000000000000000000e+00), SC_(3.7429353125000000000000000000000000000000e+05), SC_(1.3556346297264099121093750000000000000000e-01), SC_(7.0018417978574030475469012779612804921776e-23672) }},
 ^
ibeta_derivative_large_data.ipp:577:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.7700415849685668945312500000000000000000e+00), SC_(4.9033269531250000000000000000000000000000e+04), SC_(9.0580135583877563476562500000000000000000e-01), SC_(2.4241599929691788127478102157812311220157e-50297) }},
 ^
ibeta_derivative_large_data.ipp:580:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(1.8219766616821289062500000000000000000000e+00), SC_(3.9458898437500000000000000000000000000000e+04), SC_(9.6887087821960449218750000000000000000000e-01), SC_(8.3598075511032067053120419615886859032227e-59449) }},
 ^

...

ibeta_derivative_large_data.ipp:1217:1: warning: floating constant truncated to zero [-Woverflow]
 {{ SC_(4.9902409375000000000000000000000000000000e+05), SC_(3.6176475882530212402343750000000000000000e-01), SC_(2.2111195325851440429687500000000000000000e-01), SC_(1.2665423564095430817601142466738879095802e-327052) }}
 ^
gcc.link ../../../bin.v2/libs/math/test/test_ibeta_derivative_real_concept3.test/gcc-7/debug/cxxstd-03-iso/link-static/test_ibeta_derivative_real_concept3
testing.capture-output ../../../bin.v2/libs/math/test/test_ibeta_derivative_real_concept3.test/gcc-7/debug/cxxstd-03-iso/link-static/test_ibeta_derivative_real_concept3.run
**passed** ../../../bin.v2/libs/math/test/test_ibeta_derivative_real_concept3.test/gcc-7/debug/cxxstd-03-iso/link-static/test_ibeta_derivative_real_concept3.test

ibeta_derivative test failure

Compiled with:

test$ ../../../b2 --toolset=clang --compiler=clang++ cxxflags=-fsanitize=undefined linkflags=-fsanitize=undefined -j4 -a -q -d0
====== BEGIN OUTPUT ======
Running 1 test case...
Tests run with Clang version 9.1.0 (clang-902.0.39.1), libc++ version 5000, Mac OS
../../../boost/math/special_functions/relative_difference.hpp:86:46: runtime error: 1.18973e+4932 is outside the range of representable values of type 'double'
Testing Incomplete Beta Function Derivative: Small Values with type double
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
beta (incomplete)<double> Max = 0.7161 RMS Mean=0.03203
    worst case at row: 320
    { 6.3578672409057617, 7.7779402732849121, 0.96864354610443115, 6.6587600748516125e-07 }

beta (incomplete, internal call test)<double> Max = 13.4 RMS Mean=2.624
    worst case at row: 492
    { 9.7974834442138672, 3.5463814735412598, 0.438926100730896, 0.23326106479092035 }

Testing Incomplete Beta Function Derivative: Medium Values with type double
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
beta (incomplete)<double> Max = 60.75 RMS Mean=2.717
    worst case at row: 3
    { 1.1902070045471191, 72.695472717285156, 0.19963125884532928, 1.5321906748924116e-05 }

beta (incomplete, internal call test)<double> Max = 105.6 RMS Mean=20.4
    worst case at row: 469
    { 93.401069641113281, 96.496635437011719, 0.18903611600399017, 1.1333723070206939e-18 }

Testing Incomplete Beta Function Derivative: Large and Diverse Values with type double
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
beta (incomplete)<double> Max = 1.456 RMS Mean=0.0847
    worst case at row: 225
    { 0.0012384754372760653, 4809.8876953125, 0.12707412242889404, 1.4433873458058292e-286 }

beta (incomplete, internal call test)<double> Max = 3227 RMS Mean=190.6
    worst case at row: 1093
    { 48850.35546875, 289555.46875, 0.13556346297264099, 1.7280447883075433e-45 }
Peak error greater than expected value of 3000
./handle_test_result.hpp:172: error: in "test_main": check bounds.first >= max_error_found has failed

Testing Incomplete Beta Function Derivative: Small Integer Values with type double
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
beta (incomplete)<double> Max = 11.74 RMS Mean=0.4647
    worst case at row: 83
    { 1, 33, 0.30823621153831482, 0.00024955387659880056 }

beta (incomplete, internal call test)<double> Max = 34.93 RMS Mean=8.427
    worst case at row: 375
    { 13, 29, 0.81474220752716064, 6.1650314325423143e-11 }


*** 1 failure is detected in the test module "Master Test Suite"

EXIT STATUS: 201
====== END OUTPUT ======
...failed updating 1 target...

Compile fail using Clang 600 missing mutable boost::math::detail::atomic_unsigned_type

I:\modular-boost\boost/math/quadrature/detail/tanh_sinh_detail.hpp:174:33: error: no type named 'atomic_unsigned_type' in namespace 'boost::math::detail'

mutable boost::math::detail::atomic_unsigned_type m_committed_refinements;

#ifdef BOOST_MATH_NO_ATOMIC_INT
#error "Ooops"
#endif

fires, but #undef still fails.

codeblocks test_lambertw.log

(Works for gcc 8.1 and 7.2 and VS)

Incorrect result associated laguerre function

While debugging a program I noticed that the reason for the incorrect results are caused by incorrect output from the associated laguerre functions. Most of the results I get are correct (verified with MATLAB output), but for specific values of n and m the results are wrong (laguerre(n, m, x)). I noticed that in the test_laguerre function only positive values of n and m are considered. The incorrect results are produced with negative m values.

For example:
laguerre(2, -2, 5) = -1.07374e10 while the correct result is 12.5
laguerre(2, -1, 5) = 7.5 which is correct
laguerre(3, -3, 5) = -6.14891e18 while the correct result is -20.8333
laguerre(3, -2, 5) = 7.15828e9 while the correct result is -8.3333
laguerre(3, -1, 5) = -0.83333 which is correct

The associated laguerre functions are implemented using a recursive relation based on
L_{n+1}^m = (C_1 * L_{n}^m - C_2 * L_{n-1}^m)/C_3

Add nvcc to test matrix

The goal here is to make sure that no host code is broken when using nvcc; clearly at this point we have no device code. (Actually, is this an feature request for boost.config?)

erf<double>() always returns NaN on certain Android-x86 devices (e.g. K900)

boost::math::erf(double) returns NaN for normal argument (e.g. 1.5, 2...) on certain Android-x86 devices (e.g. K900, Intel Atom Z2580). The same binary works normally on Android emulator and other Android-x86 devices.

boost::math::erf(float) does not have the same problem so the easiest workaround is to use only the float version.

Used compiler: gcc 4.9 (NDK r10e), possibly relevant options:
-march=atom -mtune=atom -m32 -msse3 -mfpmath=sse -fstrict-aliasing -ffast-math -O2 -fno-reciprocal-math

Some Atom-based notebooks with Windows or Linux could also be affected by this problem.