123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152 |
- <html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
- <title>FAQ</title>
- <link rel="stylesheet" href="../../multiprecision.css" type="text/css">
- <meta name="generator" content="DocBook XSL Stylesheets V1.79.1">
- <link rel="home" href="../../index.html" title="Chapter 1. Boost.Multiprecision">
- <link rel="up" href="../map.html" title="Roadmap">
- <link rel="prev" href="todo.html" title="TODO">
- <link rel="next" href="ack.html" title="Acknowledgements">
- </head>
- <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
- <table cellpadding="2" width="100%"><tr>
- <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../../boost.png"></td>
- <td align="center"><a href="../../../../../../index.html">Home</a></td>
- <td align="center"><a href="../../../../../../libs/libraries.htm">Libraries</a></td>
- <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td>
- <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td>
- <td align="center"><a href="../../../../../../more/index.htm">More</a></td>
- </tr></table>
- <hr>
- <div class="spirit-nav">
- <a accesskey="p" href="todo.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../map.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="ack.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
- </div>
- <div class="section">
- <div class="titlepage"><div><div><h3 class="title">
- <a name="boost_multiprecision.map.faq"></a><a class="link" href="faq.html" title="FAQ">FAQ</a>
- </h3></div></div></div>
- <div class="variablelist">
- <p class="title"><b></b></p>
- <dl class="variablelist">
- <dt><span class="term">Why do I get compiler errors when passing a <code class="computeroutput"><span class="identifier">number</span></code>
- to a template function?</span></dt>
- <dd><p>
- 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.
- </p></dd>
- <dt><span class="term">When is expression template support a performance gain?</span></dt>
- <dd><p>
- 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.
- </p></dd>
- <dt><span class="term">Do expression templates reorder operations?</span></dt>
- <dd><p>
- 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.
- </p></dd>
- <dt><span class="term">I can't construct my number type from <span class="emphasis"><em>some other type</em></span>,
- but the docs indicate that the conversion should be allowed, what's up?</span></dt>
- <dd><p>
- Some conversions are <span class="emphasis"><em>explicit</em></span>, 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).
- </p></dd>
- <dt><span class="term">Why do I get an exception thrown (or the program crash due to an
- uncaught exception) when using the bitwise operators on a checked <code class="computeroutput"><span class="identifier">cpp_int</span></code>?</span></dt>
- <dd><p>
- 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 <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">range_error</span></code> being thrown.
- </p></dd>
- <dt><span class="term">Why do I get compiler errors when trying to use the complement operator?</span></dt>
- <dd><p>
- 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 <code class="computeroutput"><span class="identifier">cpp_int</span></code>'s.
- Unchecked <code class="computeroutput"><span class="identifier">cpp_int</span></code>'s
- give the same valued result as a 2's complement type would, but not
- the same bit-pattern.
- </p></dd>
- <dt><span class="term">Why can't I negate an unsigned type?</span></dt>
- <dd><p>
- The unary negation operator is deliberately disabled for unsigned integer
- types as its use would almost always be a programming error.
- </p></dd>
- <dt><span class="term">Why doesn't the library use proto?</span></dt>
- <dd><p>
- 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...
- </p></dd>
- <dt><span class="term">Why not abstract out addition/multiplication algorithms?</span></dt>
- <dd><p>
- This was deemed not to be practical: these algorithms are intimately
- tied to the actual data representation used.
- </p></dd>
- <dt><span class="term">How do I choose between Boost.Multiprecision <code class="computeroutput"><span class="identifier">cpp_bin_50</span></code>
- and <code class="computeroutput"><span class="identifier">cpp_dec_50</span></code>?</span></dt>
- <dd>
- <p>
- Unless you have a specific reason to choose <code class="computeroutput"><span class="identifier">cpp_dec_</span></code>,
- then the default choice should be <code class="computeroutput"><span class="identifier">cpp_bin_</span></code>,
- for example using the convenience <code class="computeroutput"><span class="identifier">typedefs</span></code>
- like <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">multiprecision</span><span class="special">::</span><span class="identifier">cpp_bin_50</span></code> or <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">multiprecision</span><span class="special">::</span><span class="identifier">cpp_bin_100</span></code>.
- </p>
- <p>
- In general, both work well and give the same results and at roughly
- the same speed with <code class="computeroutput"><span class="identifier">cpp_dec_50</span></code>
- sometimes faster.
- </p>
- <p>
- <code class="computeroutput"><span class="identifier">cpp_dec_</span></code> was developed
- first paving the way for <code class="computeroutput"><span class="identifier">cpp_bin_</span></code>.
- <code class="computeroutput"><span class="identifier">cpp_dec_</span></code> 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 <span class="bold"><strong>https://svn.boost.org/trac10/ticket/12133</strong></span>.
- It also has a fast but imprecise division operator giving surprising
- results sometimes, see <span class="bold"><strong>https://svn.boost.org/trac10/ticket/11178</strong></span>.
- </p>
- <p>
- <code class="computeroutput"><span class="identifier">cpp_bin_</span></code> is correctly/exactly
- rounded making it possible to reason about both the precision and rounding
- of the results.
- </p>
- </dd>
- </dl>
- </div>
- </div>
- <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
- <td align="left"></td>
- <td align="right"><div class="copyright-footer">Copyright © 2002-2019 John Maddock
- and Christopher Kormanyos<p>
- Distributed under the Boost Software License, Version 1.0. (See accompanying
- file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
- </p>
- </div></td>
- </tr></table>
- <hr>
- <div class="spirit-nav">
- <a accesskey="p" href="todo.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../map.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="ack.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
- </div>
- </body>
- </html>
|