153 lines
10 KiB
HTML
153 lines
10 KiB
HTML
<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>
|