Merge to Master for 1.90

.github/workflows/codecov.yml

@@ -61,7 +61,7 @@ jobs:
     #timeout-minutes: 120
     runs-on: ${{matrix.os}}
     container: ${{matrix.container}}
-    env: {B2_USE_CCACHE: 1}
+    env: {B2_USE_CCACHE: 0}
 
     steps:
       - name: Setup environment

README.md

@@ -26,7 +26,7 @@ requiring extended range and precision.
 
 Multiprecision consists of a generic interface to the mathematics
 of large numbers as well as a selection of big number backends.
-This includes interfaces to GMP, MPFR, MPIR and TomMath
+These include interfaces to GMP, MPFR, MPIR and TomMath
 and also Multiprecision's own collection of Boost-licensed,
 header-only backends for integers, rationals, floats and complex-floats.
 
@@ -42,6 +42,9 @@ This usually provides better performance than using types configured without exp
 
 The full documentation is available on [boost.org](http://www.boost.org/doc/libs/release/libs/multiprecision/index.html).
 
+A practical, comprehensive, instructive, clear and very helpful video regarding the use of Multiprecision
+can be found [here](https://www.youtube.com/watch?v=mK4WjpvLj4c).
+
 ## Using Multiprecision
 
 <p align="center">

config/Jamfile.v2

@@ -1,7 +1,7 @@
 # copyright John Maddock 2008
 # Distributed under the Boost Software License, Version 1.0.
 # (See accompanying file LICENSE_1_0.txt or copy at
-# http://www.boost.org/LICENSE_1_0.txt.
+# http://www.boost.org/LICENSE_1_0.txt)
 
 import-search /boost/config/checks ;
 

doc/html/boost_multiprecision/tut/interval.html

@@ -32,7 +32,7 @@
         There is one currently only one interval number type supported - <a href="http://perso.ens-lyon.fr/nathalie.revol/software.html" target="_top">MPFI</a>.
       </p>
 <p>
-        [ section:mpfi mpfi_float]
+        [section:mpfi mpfi_float]
       </p>
 </div>
 <div class="copyright-footer">Copyright © 2002-2020 John

doc/introduction.qbk

@@ -60,7 +60,7 @@ but a header-only Boost license version is always available (if somewhat slower)
 
 Should you just wish to 'cut to the chase' just to get bigger integers and/or bigger and more precise reals as simply and portably as possible,
 close to 'drop-in' replacements for the __fundamental_type analogs,
-then use a fully Boost-licensed number type, and skip to one of more of :
+then use a fully Boost-licensed number type, and skip to one or more of:
 
 * __cpp_int for multiprecision integers, 
 * __cpp_rational for rational types,
@@ -133,8 +133,8 @@ Conversions are also allowed:
 
 However conversions that are inherently lossy are either declared explicit or else forbidden altogether:
 
-   d = 3.14;  // Error implicit conversion from double not allowed.
-   d = static_cast<mp::int512_t>(3.14);  // OK explicit construction is allowed
+   d = 3.14;  // Error, implicit conversion from double not allowed.
+   d = static_cast<mp::int512_t>(3.14);  // OK, explicit construction is allowed
 
 Mixed arithmetic will fail if the conversion is either ambiguous or explicit:
 
@@ -195,9 +195,9 @@ of references to the arguments of the function, plus some compile-time informati
 is.
 
 The great advantage of this method is the ['elimination of temporaries]: for example, the "naive" implementation
-of `operator*` above, requires one temporary for computing the result, and at least another one to return it.  It's true
+of `operator*` above requires one temporary for computing the result, and at least another one to return it.  It's true
 that sometimes this overhead can be reduced by using move-semantics, but it can't be eliminated completely.  For example,
-lets suppose we're evaluating a polynomial via Horner's method, something like this:
+let's suppose we're evaluating a polynomial via Horner's method, something like this:
 
     T a[7] = { /* some values */ };
     //....
@@ -206,9 +206,9 @@ lets suppose we're evaluating a polynomial via Horner's method, something like t
 If type `T` is a `number`, then this expression is evaluated ['without creating a single temporary value].  In contrast,
 if we were using the [mpfr_class] C++ wrapper for [mpfr] - then this expression would result in no less than 11
 temporaries (this is true even though [mpfr_class] does use expression templates to reduce the number of temporaries somewhat).  Had
-we used an even simpler wrapper around [mpfr] like [mpreal] things would have been even worse and no less that 24 temporaries
+we used an even simpler wrapper around [mpfr] like [mpreal] things would have been even worse and no less than 24 temporaries
 are created for this simple expression (note - we actually measure the number of memory allocations performed rather than
-the number of temporaries directly, note also that the [mpf_class] wrapper that will be supplied with GMP-5.1 reduces the number of
+the number of temporaries directly, note also that the [mpf_class] wrapper supplied with GMP-5.1 or later reduces the number of
 temporaries to pretty much zero).  Note that if we compile with expression templates disabled and rvalue-reference support
 on, then actually still have no wasted memory allocations as even though temporaries are created, their contents are moved
 rather than copied.
@@ -247,7 +247,7 @@ is created in this case.
 
 Given the comments above, you might be forgiven for thinking that expression-templates are some kind of universal-panacea:
 sadly though, all tricks like this have their downsides.  For one thing, expression template libraries
-like this one, tend to be slower to compile than their simpler cousins, they're also harder to debug
+like this one tend to be slower to compile than their simpler cousins, they're also harder to debug
 (should you actually want to step through our code!), and rely on compiler optimizations being turned
 on to give really good performance.  Also, since the return type from expressions involving `number`s
 is an "unmentionable implementation detail", you have to be careful to cast the result of an expression
@@ -256,23 +256,23 @@ to the actual number type when passing an expression to a template function.  Fo
    template <class T>
    void my_proc(const T&);
 
-Then calling:
+Then calling
 
    my_proc(a+b);
 
-Will very likely result in obscure error messages inside the body of `my_proc` - since we've passed it
+will very likely result in obscure error messages inside the body of `my_proc` - since we've passed it
 an expression template type, and not a number type.  Instead we probably need:
 
    my_proc(my_number_type(a+b));
 
 Having said that, these situations don't occur that often - or indeed not at all for non-template functions.
 In addition, all the functions in the Boost.Math library will automatically convert expression-template arguments
-to the underlying number type without you having to do anything, so:
+to the underlying number type without you having to do anything, so
 
    mpfr_float_100 a(20), delta(0.125);
    boost::math::gamma_p(a, a + delta);
 
-Will work just fine, with the `a + delta` expression template argument getting converted to an `mpfr_float_100`
+will work just fine, with the `a + delta` expression template argument getting converted to an `mpfr_float_100`
 internally by the Boost.Math library.
 
 [caution In C++11 you should never store an expression template using:
@@ -299,7 +299,7 @@ dramatic as the reduction in number of temporaries would suggest.  For example,
 we see the following typical results for polynomial execution:
 
 [table Evaluation of Order 6 Polynomial.
-[[Library]         [Relative Time]   [Relative number of memory allocations]]
+[[Library]         [Relative Time]   [Relative Number of Memory Allocations]]
 [[number]          [1.0 (0.00957s)]  [1.0 (2996 total)]]
 [[[mpfr_class]]    [1.1 (0.0102s)]   [4.3 (12976 total)]]
 [[[mpreal]]        [1.6 (0.0151s)]   [9.3 (27947 total)]]
@@ -311,13 +311,13 @@ a number of reasons for this:
 * The cost of extended-precision multiplication and division is so great, that the times taken for these tend to
 swamp everything else.
 * The cost of an in-place multiplication (using `operator*=`) tends to be more than an out-of-place
-`operator*` (typically `operator *=` has to create a temporary workspace to carry out the multiplication, where
-as `operator*` can use the target variable as workspace).  Since the expression templates carry out their
+`operator*` (typically `operator *=` has to create a temporary workspace to carry out the multiplication,
+whereas `operator*` can use the target variable as workspace).  Since the expression templates carry out their
 magic by converting out-of-place operators to in-place ones, we necessarily take this hit.  Even so the
 transformation is more efficient than creating the extra temporary variable, just not by as much as
 one would hope.
 
-Finally, note that `number` takes a second template argument, which, when set to `et_off` disables all
+Finally, note that `number` takes a second template argument, which, when set to `et_off`, disables all
 the expression template machinery.  The result is much faster to compile, but slower at runtime.
 
 We'll conclude this section by providing some more performance comparisons between these three libraries,

doc/multiprecision.qbk

@@ -132,7 +132,7 @@
 [def __compiler_support [@https://en.cppreference.com/w/cpp/compiler_support compiler support]]
 [def __ULP [@http://en.wikipedia.org/wiki/Unit_in_the_last_place  Unit in the last place (ULP)]]
 [def __Mathematica [@http://www.wolfram.com/products/mathematica/index.html Wolfram Mathematica]]
-[def __WolframAlpha [@http://www.wolframalpha.com/ Wolfram Alpha]]
+[def __WolframAlphaGLCoefs [@https://www.wolframalpha.com/input?i=Fit%5B%7B%7B21.0%2C+3.5%7D%2C+%7B51.0%2C+11.1%7D%2C+%7B101.0%2C+22.5%7D%2C+%7B201.0%2C+46.8%7D%7D%2C+%7B1%2C+d%2C+d%5E2%7D%2C+d%5D+FullSimplify%5B%25%5D Wolfram Alpha Gauss-Laguerre coefficients]]
 [def __Boost_Serialization [@https://www.boost.org/doc/libs/release/libs/serialization/doc/index.html Boost.Serialization]]
 [def __Boost_Math [@https://www.boost.org/doc/libs/release/libs/math/doc/index.html Boost.Math]]
 [def __Boost_Multiprecision [@https://www.boost.org/doc/libs/release/libs/multiprecision/doc/index.html Boost.Multiprecision]]

doc/performance.qbk

@@ -5,7 +5,7 @@
 
   Distributed under the Boost Software License, Version 1.0.
   (See accompanying file LICENSE_1_0.txt or copy at
-  http://www.boost.org/LICENSE_1_0.txt).
+  http://www.boost.org/LICENSE_1_0.txt.)
 ]
 
 [section:perf Performance Comparison]
@@ -30,7 +30,7 @@ share similar relative performances.
 
 The backends which effectively wrap GMP/MPIR and MPFR
 retain the superior performance of the low-level big-number engines.
-When these are used (in association with at least some level of optmization)
+When these are used (in association with at least some level of optimization)
 they achieve and retain the expected low-level performances.
 
 At low digit counts, however, it is noted that the performances of __cpp_int,
@@ -47,7 +47,7 @@ the performances of the Boost-licensed, self-written backends.
 At around a few hundred to several thousands of digits,
 factors of about two through five are observed,
 whereby GMP/MPIR-based calculations are (performance-wise)
-supreior ones.
+superior ones.
 
 At a few thousand decimal digits, the upper end of
 the Boost backends is reached. At the moment,

doc/performance_integer_real_world.qbk

@@ -18,16 +18,16 @@ type which was custom written for this specific task:
 
 [table
 [[Integer Type][Relative Performance (Actual time in parenthesis)]]
-[[checked_int1024_t][1.53714(0.0415328s)]]
-[[checked_int256_t][1.20715(0.0326167s)]]
-[[checked_int512_t][1.2587(0.0340095s)]]
-[[cpp_int][1.80575(0.0487904s)]]
-[[extended_int][1.35652(0.0366527s)]]
-[[int1024_t][1.36237(0.0368107s)]]
-[[int256_t][1(0.0270196s)]]
-[[int512_t][1.0779(0.0291243s)]]
-[[mpz_int][3.83495(0.103619s)]]
-[[tom_int][41.6378(1.12504s)]]
+[[checked_int1024_t][1.53714 (0.0415328s)]]
+[[checked_int256_t][1.20715 (0.0326167s)]]
+[[checked_int512_t][1.2587 (0.0340095s)]]
+[[cpp_int][1.80575 (0.0487904s)]]
+[[extended_int][1.35652 (0.0366527s)]]
+[[int1024_t][1.36237 (0.0368107s)]]
+[[int256_t][1 (0.0270196s)]]
+[[int512_t][1.0779 (0.0291243s)]]
+[[mpz_int][3.83495 (0.103619s)]]
+[[tom_int][41.6378 (1.12504s)]]
 ]
 
 Note how for this use case, any dynamic allocation is a performance killer.
@@ -38,18 +38,18 @@ since that is the rate limiting step:
 
 [table
 [[Integer Type][Relative Performance (Actual time in parenthesis)]]
-[[checked_uint1024_t][9.52301(0.0422246s)]]
-[[cpp_int][11.2194(0.0497465s)]]
-[[cpp_int (1024-bit cache)][10.7941(0.0478607s)]]
-[[cpp_int (128-bit cache)][11.0637(0.0490558s)]]
-[[cpp_int (256-bit cache)][11.5069(0.0510209s)]]
-[[cpp_int (512-bit cache)][10.3303(0.0458041s)]]
-[[cpp_int (no Expression templates)][16.1792(0.0717379s)]]
-[[mpz_int][1.05106(0.00466034s)]]
-[[mpz_int (no Expression templates)][1(0.00443395s)]]
-[[tom_int][5.10595(0.0226395s)]]
-[[tom_int (no Expression templates)][61.9684(0.274765s)]]
-[[uint1024_t][9.32113(0.0413295s)]]
+[[checked_uint1024_t][9.52301 (0.0422246s)]]
+[[cpp_int][11.2194 (0.0497465s)]]
+[[cpp_int (1024-bit cache)][10.7941 (0.0478607s)]]
+[[cpp_int (128-bit cache)][11.0637 (0.0490558s)]]
+[[cpp_int (256-bit cache)][11.5069 (0.0510209s)]]
+[[cpp_int (512-bit cache)][10.3303 (0.0458041s)]]
+[[cpp_int (no Expression templates)][16.1792 (0.0717379s)]]
+[[mpz_int][1.05106 (0.00466034s)]]
+[[mpz_int (no Expression templates)][1 (0.00443395s)]]
+[[tom_int][5.10595 (0.0226395s)]]
+[[tom_int (no Expression templates)][61.9684 (0.274765s)]]
+[[uint1024_t][9.32113 (0.0413295s)]]
 ]
 
 It's interesting to note that expression templates have little effect here - perhaps because the actual expressions involved

doc/performance_overhead.qbk

@@ -34,7 +34,7 @@ for the [@../../performance/voronoi_performance.cpp voronoi-diagram builder test
 
 [table
 [[Type][Relative time]]
-[[`int64_t`][[*1.0](0.0128646s)]]
+[[`int64_t`][[*1.0] (0.0128646s)]]
 [[`number<arithmetic_backend<int64_t>, et_off>`][1.005 (0.0129255s)]]
 ]
 

doc/performance_rational_real_world.qbk

@@ -55,7 +55,7 @@ calculate the n'th Bernoulli number via mixed rational/integer arithmetic to giv
 [[198][167.594528][0.8947434429][1.326461858]]
 ]
 
-In this use case, most the of the rational numbers are fairly small and so the times taken are dominated by
+In this use case, most of the rational numbers are fairly small and so the times taken are dominated by
 the number of allocations performed.  The following table illustrates how well each type performs on suppressing
 allocations:
 

doc/performance_real_world.qbk

@@ -23,12 +23,12 @@ increases contension inside new/delete.
 [[cpp_dec_float_50 (3 concurrent threads)][5.66114 (0.524077s)][424]]
 [[mpf_float_50][1.03648 (0.0959515s)][640961]]
 [[mpf_float_50 (3 concurrent threads)][1.50439 (0.139268s)][2563517]]
-[[mpf_float_50 (no expression templates][1 (0.0925745s)][1019039]]
-[[mpf_float_50 (no expression templates (3 concurrent threads)][1.52451 (0.141131s)][4075842]]
+[[mpf_float_50 (no expression templates)][1 (0.0925745s)][1019039]]
+[[mpf_float_50 (no expression templates) (3 concurrent threads)][1.52451 (0.141131s)][4075842]]
 [[mpfr_float_50][1.2513 (0.115838s)][583054]]
 [[mpfr_float_50 (3 concurrent threads)][1.61301 (0.149324s)][2330876]]
-[[mpfr_float_50 (no expression templates][1.42667 (0.132073s)][999594]]
-[[mpfr_float_50 (no expression templates (3 concurrent threads)][2.00203 (0.185337s)][4000039]]
+[[mpfr_float_50 (no expression templates)][1.42667 (0.132073s)][999594]]
+[[mpfr_float_50 (no expression templates) (3 concurrent threads)][2.00203 (0.185337s)][4000039]]
 [[static_mpfr_float_50][1.18358 (0.10957s)][22930]]
 [[static_mpfr_float_50 (3 concurrent threads)][1.38802 (0.128496s)][93140]]
 [[static_mpfr_float_50 (no expression templates)][1.14598 (0.106089s)][46861]]
@@ -41,9 +41,9 @@ increases contension inside new/delete.
 [[cpp_bin_float_50 (3 concurrent threads)][3.50535 (56.6s)][28]]
 [[cpp_dec_float_50][4.82763 (77.9505s)][0]]
 [[mpf_float_50][1.06817 (17.2475s)][123749688]]
-[[mpf_float_50 (no expression templates][1 (16.1468s)][152610085]]
+[[mpf_float_50 (no expression templates)][1 (16.1468s)][152610085]]
 [[mpfr_float_50][1.18754 (19.1749s)][118401290]]
-[[mpfr_float_50 (no expression templates][1.36782 (22.0858s)][152816346]]
+[[mpfr_float_50 (no expression templates)][1.36782 (22.0858s)][152816346]]
 [[static_mpfr_float_50][1.04471 (16.8686s)][113395]]
 ]