Fix mistakes (#729)

* Update Jamfile.v2

* Update introduction.qbk

* Update tutorial.qbk

* Update tutorial_cpp_int.qbk

* Update tutorial_gmp_int.qbk

* Update tutorial_tommath.qbk

* Update integer_examples.cpp

* Update tutorial_cpp_bin_float.qbk

* Update tutorial_cpp_dec_float.qbk

* Update tutorial_gmp_float.qbk

* Update tutorial_mpfr_float.qbk

* Update tutorial_float128.qbk

* Update tutorial_float_builtin_ctor.qbk

* Update big_seventh.cpp

* Update tutorial_float_eg.qbk

* Update floating_point_examples.cpp

* Update mpfr_precision.cpp

* Update gauss_laguerre_quadrature.cpp

* Update tutorial_interval_mpfi.qbk

* Update tutorial_cpp_complex.qbk

* Update tutorial_mpc_complex.qbk

* Update tutorial_float128_complex.qbk

* Update tutorial_complex_adaptor.qbk

* Update tutorial_rational.qbk

* Update tutorial_tommath_rational.qbk

* Update tutorial_logged_adaptor.qbk

* Update tutorial_debug_adaptor.qbk

* Update tutorial_visualizers.qbk

* Update tutorial_fwd.qbk

* Update tutorial_conversions.qbk

* Update tutorial_random.qbk

* Update random_snips.cpp

* Update tutorial_constexpr.qbk

* Update tutorial_import_export.qbk

* Update cpp_int_import_export.cpp

* Update tutorial_mixed_precision.qbk

* Update tutorial_variable_precision.qbk

* Update scoped_precision_example.cpp

* Update tutorial_numeric_limits.qbk

* Update tutorial_numeric_limits.qbk

* Update numeric_limits_snips.cpp

* Update numeric_limits_snips.cpp

* Update tutorial_numeric_limits.qbk

* Update numeric_limits_snips.cpp

* Update numeric_limits_snips.cpp

* Update tutorial_io.qbk

* Update reference_number.qbk

* Update reference_cpp_bin_float.qbk

* Update reference_cpp_double_fp_backend.qbk

* Update reference_internal_support.qbk

* Update reference_backend_requirements.qbk

* Update performance.qbk

* Update performance_overhead.qbk

* Update performance_real_world.qbk

* Update performance_integer_real_world.qbk

* Update performance_rational_real_world.qbk

* Update reference_number.qbk

* Update tutorial_numeric_limits.qbk

* Update reference_backend_requirements.qbk

Author: ivanpanch

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/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,7 +206,7 @@ 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 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
@@ -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/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]]
 ]