Ticket #7806: fix_typo.patch

boost/multiprecision/detail/generic_interconvert.hpp

@@ -114 +114 @@
 #endif
    //
    // The code here only works when the radix of "From" is 2, we could try shifting by other
-   // radixes but it would complicate things.... use a string convertion when the radix is other
+   // radixes but it would complicate things.... use a string conversion when the radix is other
    // than 2:
    //
    if(std::numeric_limits<number<From> >::radix != 2)

boost/multiprecision/detail/functions/pow.hpp

@@ -535 +535 @@
 template<class T, class A> 
 inline typename enable_if<is_floating_point<A>, void>::type eval_pow(T& result, const T& x, const A& a)
 {
-   // Note this one is resticted to float arguments since pow.hpp already has a version for
+   // Note this one is restricted to float arguments since pow.hpp already has a version for
    // integer powers....
    typedef typename boost::multiprecision::detail::canonical<A, T>::type canonical_type;
    typedef typename mpl::if_<is_same<A, canonical_type>, T, canonical_type>::type cast_type;

boost/multiprecision/detail/default_ops.hpp

@@ -862 +862 @@
 inline void eval_convert_to(terminal<R>* result, const B& backend)
 {
    //
-   // We ran out of types to try for the convertion, try
+   // We ran out of types to try for the conversion, try
    // a lexical_cast and hope for the best:
    //
    result->value = boost::lexical_cast<R>(backend.str(0, std::ios_base::fmtflags(0)));

boost/multiprecision/random.hpp

@@ -500 +500 @@
         // (range+1)/(brange+1) > limit+1                by (5)              (6)
         // limit < floor((range+1)/(brange+1))           by (6)              (7)
         // limit==floor((range+1)/(brange+1))            def. of limit       (8)
-        // not (2)                                       reductio            (9)
+        // not (2)                                       reduction           (9)
         //
         // loop postcondition: (range/mult)*mult+(mult-1) >= range
         //
@@ -523 +523 @@
                 static_cast<range_type>(range/mult),
                 boost::mpl::true_());
         if(std::numeric_limits<range_type>::is_bounded && ((std::numeric_limits<range_type>::max)() / mult < result_increment)) {
-          // The multiplcation would overflow.  Reject immediately.
+          // The multiplication would overflow.  Reject immediately.
           continue;
         }
         result_increment *= mult;

boost/multiprecision/cpp_dec_float.hpp

@@ -812 +812 @@
    bool overflow = exp >= cpp_dec_float_max_exp10;
    if(exp == cpp_dec_float_max_exp10)
    {
-      // Check to see if we really truely have an overflow or not...
+      // Check to see if we really truly have an overflow or not...
       if(isneg())
       {
          cpp_dec_float t(*this);

boost/multiprecision/cpp_int/cpp_int_config.hpp

@@ -19 +19 @@
 
 //
 // These traits calculate the largest type in the list
-// [unsigned] ong long, long, int, which has the specified number
+// [unsigned] long long, long, int, which has the specified number
 // of bits.  Note that intN_t and boost::int_t<N> find the first
 // member of the above list, not the last.  We want the last in the 
 // list to ensure that mixed arithmetic operations are as efficient 
@@ -61 +61 @@
    >::type type;
 };
 
-} // namepsace detail
+} // namespace detail
 
 #if defined(BOOST_HAS_INT128)
 

boost/multiprecision/cpp_int/bitwise.hpp

@@ -351 +351 @@
 }
 
 //
-// Over agin for trivial cpp_int's:
+// Over again for trivial cpp_int's:
 //
 template <unsigned MinBits1, unsigned MaxBits1, cpp_integer_type SignType1, cpp_int_check_type Checked1, class Allocator1, class T>
 BOOST_MP_FORCEINLINE typename enable_if<is_trivial_cpp_int<cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1> > >::type

boost/multiprecision/cpp_int/checked.hpp

@@ -10 +10 @@
 
 //
 // Simple routines for performing checked arithmetic with a builtin arithmetic type.
-// Note that is is not a complete header, it must be included as part of boost/multiprecision/cpp_int.hpp.
+// Note that this is not a complete header, it must be included as part of boost/multiprecision/cpp_int.hpp.
 //
 
 inline void raise_overflow(std::string op)

boost/multiprecision/cpp_int/add.hpp

@@ -79 +79 @@
 template <class CppInt1, class CppInt2>
 inline void add_unsigned(CppInt1& result, const CppInt2& a, const limb_type& o) BOOST_NOEXCEPT_IF(is_non_throwing_cpp_int<CppInt1>::value)
 {
-   // Addition using modular arithmatic.
+   // Addition using modular arithmetic.
    // Nothing fancy, just let uintmax_t take the strain:
    if(&result != &a)
       result.resize(a.size(), a.size());

boost/multiprecision/number.hpp

@@ -355 +355 @@
    // even if the result of the operator *is never used*.
    // Possibly we could modify our expression wrapper to
    // execute the increment/decrement on destruction, but
-   // correct implemetation will be tricky, so defered for now...
+   // correct implementation will be tricky, so deferred for now...
    //
    BOOST_MP_FORCEINLINE number& operator++()
    {
@@ -1687 +1687 @@
    a.swap(b);
 }
 
-}  // namespace multipreciion
+}  // namespace multiprecision
 
 template <class T>
 class rational;

libs/multiprecision/test/test_cpp_int.cpp

@@ -325 +325 @@
       if(!std::numeric_limits<test_type>::is_modulo)
       {
          // We have to take care that our powers don't grow too large, otherwise this takes "forever",
-         // also don't test for modulo types, as these may give a diffferent result from arbitrary
+         // also don't test for modulo types, as these may give a different result from arbitrary
          // precision types:
          BOOST_CHECK_EQUAL(mpz_int(pow(d, ui % 19)).str(), test_type(pow(d1, ui % 19)).str());
          BOOST_CHECK_EQUAL(mpz_int(powm(a, b, c)).str(), test_type(powm(a1, b1, c1)).str());

libs/multiprecision/doc/multiprecision.qbk

@@ -510 +510 @@
 * When used at fixed precision, the size of this type is always one machine word larger than you would expect for an N-bit integer: 
 the extra word stores both the sign, and how many machine words in the integer are actually in use.  
 The latter is an optimisation for larger fixed precision integers, so that a 1024-bit integer has almost the same performance
-characterists as a 128-bit integer, rather than being 4 times slower for addition and 16 times slower for multiplication
+characteristics as a 128-bit integer, rather than being 4 times slower for addition and 16 times slower for multiplication
  (assuming the values involved would always fit in 128 bits).
 Typically this means you can use
 an integer type wide enough for the "worst case senario" with only minor performance degradation even if most of the time
@@ -655 +655 @@
 The typedefs `cpp_dec_float_50` and `cpp_dec_float_100` provide arithmetic types at 50 and 100 decimal digits precision
 respectively.  Optionally, you can specify an integer type to use for the exponent, this defaults to a 32-bit integer type
 which is more than large enough for the vast majority of use cases, but larger types such as `long long` can also be specified
-if you need a truely huge exponent range.  In any case the ExponentType must be a built in signed integer type at least 2 bytes 
+if you need a truly huge exponent range.  In any case the ExponentType must be a built in signed integer type at least 2 bytes 
 and 16-bits wide.
 
 Normally `cpp_dec_float` allocates no memory: all of the space required for its digits are allocated
@@ -797 +797 @@
 or stack allocation (where all the memory required for the underlying data types is stored
 within `mpfr_float_backend`).  The latter option can result in significantly faster code, at the
 expense of growing the size of `mpfr_float_backend`.  It can only be used at fixed precision, and
-should only be used for lower digit counts.  Note that we can not guarentee that using `allocate_stack`
+should only be used for lower digit counts.  Note that we can not guarantee that using `allocate_stack`
 won't cause any calls to mpfr's allocation routines, as mpfr may call these inside it's own code.
 The following table gives an idea of the performance tradeoff's at 50 decimal digits 
 precision[footnote Compiled with VC++10 and /Ox, with MPFR-3.0.0 and MPIR-2.3.0]:
@@ -1135 +1135 @@
 
    int128_t     i128 = 0;
    int266_t     i256 = i128;  // OK implicit widening conversion
-   i128_t            = i256;  // Error, no assignment operator found, narrowing conversion is explict
+   i128_t            = i256;  // Error, no assignment operator found, narrowing conversion is explicit
    i128_t            = static_cast<int128_t>(i256); // OK, explicit narrowing conversion
 
    mpz_int      z    = 0;
@@ -1166 +1166 @@
    mpf_float i(m);        // copies the value of the native type.
 
 More information on what additional types a backend supports conversions from are given in the tutorial for each backend.
-The converting constructor will be implict if the backend's converting constructor is also implicit, and explicit if the
+The converting constructor will be implicit if the backend's converting constructor is also implicit, and explicit if the
 backends converting constructor is also explicit.
 
 [endsect]
@@ -1839 +1839 @@
 Also note that with the exception of `abs` that these functions can only be used with floating-point Backend types (if any other types
 such as fixed precision or complex types are added to the library later, then these functions may be extended to support those number types).
 
-The precision of these functions is generally deterimined by the backend implementation.  For example the precision
+The precision of these functions is generally determined by the backend implementation.  For example the precision
 of these functions when used with __mpfr_float_backend is determined entirely by [mpfr].  When these functions use our own
-implementations, the accuracy of the transcendal functions is generally a few epsilon.  Note however, that the trigonmetrical
+implementations, the accuracy of the transcendental functions is generally a few epsilon.  Note however, that the trigonometrical
 functions incur the usual accuracy loss when reducing arguments by large multiples of [pi].  Also note that both __mpf_float
 and __cpp_dec_float have a number of guard digits beyond their stated precision, so the error rates listed for these
 are in some sense artificially low.
@@ -2311 +2311 @@
 [[`b = b`][`B&`][Assignment operator.][[space]]]
 [[`b = a`][`B&`][Assignment from an Arithmetic type.  The type of `a` shall be listed in one of the type lists
             `B::signed_types`, `B::unsigned_types` or `B::float_types`.][[space]]]
-[[`b = s`][`B&`][Assignment from a string.][Throws a `std::runtime_error` if the string could not be interpretted as a valid number.]]
+[[`b = s`][`B&`][Assignment from a string.][Throws a `std::runtime_error` if the string could not be interpreted as a valid number.]]
 [[`b.swap(b)`][`void`][Swaps the contents of its arguments.][`noexcept`]]
 [[`cb.str(ui, bb)`][`std::string`][Returns the string representation of `b` with `ui` digits and in scientific format if `bb` is `true`.
                   If `ui` is zero, then returns as many digits as are required to reconstruct the original value.][[space]]]
@@ -2472 +2472 @@
             When not provided does the equivalent of `eval_multiply(b, cb, cb2)` followed by
             `eval_add(b, cb3)`.
             For brevity, only a version showing all arguments of type `B` is shown here, but you can replace up to any 2 of
-            `cb`, `cb2` and `cb3` with any type type listed in one of the type lists
+            `cb`, `cb2` and `cb3` with any type listed in one of the type lists
             `B::signed_types`, `B::unsigned_types` or `B::float_types`.][[space]]]
 [[`eval_multiply_subtract(b, cb, cb2, cb3)`][`void`][Multiplies `cb` by `cb2` and subtracts from the result `cb3` storing the result in `b`.
             When not provided does the equivalent of `eval_multiply(b, cb, cb2)` followed by
             `eval_subtract(b, cb3)`.
             For brevity, only a version showing all arguments of type `B` is shown here, but you can replace up to any 2 of
-            `cb`, `cb2` and `cb3` with any type type listed in one of the type lists
+            `cb`, `cb2` and `cb3` with any type listed in one of the type lists
             `B::signed_types`, `B::unsigned_types` or `B::float_types`.][[space]]]
 [[`eval_divide(b, a)`][`void`][Divides `b` by `a`.  The type of `a` shall be listed in one of the type lists
             `B::signed_types`, `B::unsigned_types` or `B::float_types`.
@@ -2677 +2677 @@
 [[rational_adapter.hpp][Defines the `rational_adapter` backend.]]
 [[cpp_dec_float.hpp][Defines the `cpp_dec_float` backend.]]
 [[tommath.hpp][Defines the `tommath_int` backend.]]
-[[concepts/number_archetypes.hpp][Defines a backend concept architypes for testing use.]]
+[[concepts/number_archetypes.hpp][Defines a backend concept archetypes for testing use.]]
 ]
 
 [table Implementation Headers]
@@ -3379 +3379 @@
 * Add a back-end for MPFR interval arithmetic.
 * Add better multiplication routines (Karatsuba, FFT etc) to cpp_int_backend.
 * Add assembly level routines to cpp_int_backend.
-* Add an all C++ Boost licenced binary floating point type.
+* Add an all C++ Boost licensed binary floating point type.
 * Can ring types (exact floating point types) be supported?  The answer should be yes, but someone needs to write it, 
-the hard part is IO and binary-decimal convertion.
+the hard part is IO and binary-decimal conversion.
 * Should there be a choice of rounding mode (probably MPFR specific)?
 * We can reuse temporaries in multiple subtrees (temporary caching).
 * cpp_dec_float should round to nearest.
@@ -3405 +3405 @@
 * Each back-end should document the requirements it satisfies (not currently scheduled for inclusion: it's
 deliberately an implementation detail, and "optional" requirements are optimisations which can't be detected
 by the user).  Not done: this is an implementation detail, the exact list of requirements satisfied is purely
-an optimimization, not something the user can detect.
+an optimization, not something the user can detect.
 * A backend for an overflow aware integers (done 2012/10/31).
 * IIUC convert_to is used to emulate in c++98 compilers C++11 explicit 
 conversions. Could the explicit conversion operator be added on 
@@ -3421 +3421 @@
 * The library interface should use the noexcept (BOOST_NOEXCEPT, ...) 
 facilities (Done 2012/09/15).
 * It is unfortunate that the generic mp_number front end can not make use 
-contexpr as not all the backends can ensure this (done - we can go quite a way).
+constexpr as not all the backends can ensure this (done - we can go quite a way).
 * literals: The library doesn't provide some kind of literals. I think that the 
 mp_number class should provide a way to create literals if the backend 
 is able to.  (Done 2012/09/15).
@@ -3436 +3436 @@
 template argument that defaults to 0 (meaning keep going till no more space/memory).  Done.
 * Can ring types (exact floating point types) be supported?  The answer should be yes, but someone needs to write it (Moved to TODO list).
 * Should there be a choice of rounding mode (probably MPFR specific)?  Moved to TODO list.
-* Make the exponent type for cpp_dec_float a templare parameter, maybe include support for big-integer exponents.
+* Make the exponent type for cpp_dec_float a template parameter, maybe include support for big-integer exponents.
 Open question - what should be the default - int32_t or int64_t?  (done 2012/09/06)
 * Document the size requirements of fixed precision ints (done 2012/09/15).
 * Document std lib function accuracy (done 2012/09/15).
@@ -3488 +3488 @@
    proto has to offer anyway, a lightweight expression template mechanism was used instead.
    Compile times are still too slow...]]
 [[Why not abstract out addition/multiplication algorithms?]
-   [This was deamed not to be practical: these algorithms are intimately
+   [This was deemed not to be practical: these algorithms are intimately
    tied to the actual data representation used.]]
 ]
 

libs/multiprecision/doc/html4_symbols.qbk

@@ -10 +10 @@
 [/ http://www.htmlhelp.com/reference/html40/entities/latin1.html]
 [/Unicode Latin extended http://www.unicode.org/charts/U0080.pdf]
 
-[/ Also some miscellaneous math charaters added to this list - see the end.]
+[/ Also some miscellaneous math characters added to this list - see the end.]
 [/ For others see also math_symbols.qbk]
 
 [/ To use, enclose the template name in square brackets.]

libs/multiprecision/example/floating_point_examples.cpp

@@ -163 +163 @@
 
    JEL(cpp_dec_float_50(v + 0.5), z);
 
-However, if we want the function JEL to be truely reusable, then a better solution might be preferred.
+However, if we want the function JEL to be truly reusable, then a better solution might be preferred.
 To achieve this we can borrow some code from Boost.Math which calculates the return type of mixed-argument
 functions, here's how the new code looks now:
 
@@ -543 +543 @@
    // to handle expression templates etc.  As a result it's hard to take its
    // address without knowing about its implementation details.  We'll use a 
    // C++11 lambda expression to capture the call.
-   // We also need a typecast on the first argument so we don't accidently pass
+   // We also need a typecast on the first argument so we don't accidentally pass
    // an expression template to a template function:
    //
    const cpp_dec_float_50 d_mp = derivative(