| Home | Libraries | People | FAQ | More

### FAQ

Why do I get compiler errors when passing a `number` to a template function?

  Most likely you are actually passing an expression template type to the function and template-argument-deduction deduces the "wrong" type. Try casting the arguments involving expressions to the actual number type, or as a last resort turning off expression template support in the number type you are using.

When is expression template support a performance gain?

  As a general rule, expression template support adds a small runtime overhead creating and unpacking the expression templates, but greatly reduces the number of temporaries created. So it's most effective in improving performance when the cost of creating a temporary is high: for example when creating a temporary involves a memory allocation. It is least effective (and may even be a dis-optimisation) when temporaries are cheap: for example if the number type is basically a thin wrapper around a native arithmetic type. In addition, since the library makes extensive use of thin inline wrapper functions, turning on compiler optimization is essential to achieving high performance.

Do expression templates reorder operations?

  Yes they do, sometimes quite radically so, if this is a concern then they should be turned off for the number type you are using.

I can't construct my number type from some other type, but the docs indicate that the conversion should be allowed, what's up?

  Some conversions are explicit, that includes construction from a string, or constructing from any type that may result in loss of precision (for example constructing an integer type from a float).

Why do I get an exception thrown (or the program crash due to an uncaught exception) when using the bitwise operators on a checked `cpp_int`?

  Bitwise operations on negative values (or indeed any signed integer type) are unspecified by the standard. As a result any attempt to carry out a bitwise operation on a negative checked-integer will result in a `std::range_error` being thrown.

Why do I get compiler errors when trying to use the complement operator?

  Use of the complement operator on signed types is problematic as the result is unspecified by the standard, and is further complicated by the fact that most extended precision integer types use a sign-magnitude representation rather than the 2's complement one favored by most native integer types. As a result the complement operator is deliberately disabled for checked `cpp_int`'s. Unchecked `cpp_int`'s give the same valued result as a 2's complement type would, but not the same bit-pattern.

Why can't I negate an unsigned type?

  The unary negation operator is deliberately disabled for unsigned integer types as its use would almost always be a programming error.

Why doesn't the library use proto?

  A very early version of the library did use proto, but compile times became too slow for the library to be usable. Since the library only required a tiny fraction of what 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 deemed not to be practical: these algorithms are intimately tied to the actual data representation used.

How do I choose between Boost.Multiprecision `cpp_bin_50` and `cpp_dec_50`?

  Unless you have a specific reason to choose `cpp_dec_`, then the default choice should be `cpp_bin_`, for example using the convenience `typedefs` like `boost::multiprecision::cpp_bin_50` or `boost::multiprecision::cpp_bin_100`.

  In general, both work well and give the same results and at roughly the same speed with `cpp_dec_50` sometimes faster.

  `cpp_dec_` was developed first paving the way for `cpp_bin_`. `cpp_dec_` has several guard digits and is not rounded at all, using 'brute force' to get the promised number of decimal digits correct, but making it difficult to reason about precision and computational uncertainty, for example see https://svn.boost.org/trac10/ticket/12133. It also has a fast but imprecise division operator giving surprising results sometimes, see https://svn.boost.org/trac10/ticket/11178.

  `cpp_bin_` is correctly/exactly rounded making it possible to reason about both the precision and rounding of the results.