1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>Relative Error</title>
<link rel="stylesheet" href="../../../../../../../doc/src/boostbook.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
<link rel="home" href="../../index.html" title="Math Toolkit">
<link rel="up" href="../backgrounders.html" title="Backgrounders">
<link rel="prev" href="implementation.html" title="Additional Implementation Notes">
<link rel="next" href="lanczos.html" title="The Lanczos Approximation">
</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="implementation.html"><img src="../../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../backgrounders.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="lanczos.html"><img src="../../../../../../../doc/src/images/next.png" alt="Next"></a>
</div>
<div class="section math_toolkit_backgrounders_relative_error">
<div class="titlepage"><div><div><h3 class="title">
<a name="math_toolkit.backgrounders.relative_error"></a><a class="link" href="relative_error.html" title="Relative Error">Relative Error</a>
</h3></div></div></div>
<p>
Given an actual value <span class="emphasis"><em>a</em></span> and a found value <span class="emphasis"><em>v</em></span>
the relative error can be calculated from:
</p>
<p>
<span class="inlinemediaobject"><img src="../../../equations/error2.png"></span>
</p>
<p>
However the test programs in the library use the symmetrical form:
</p>
<p>
<span class="inlinemediaobject"><img src="../../../equations/error1.png"></span>
</p>
<p>
which measures <span class="emphasis"><em>relative difference</em></span> and happens to be
less error prone in use since we don't have to worry which value is the "true"
result, and which is the experimental one. It guarantees to return a value
at least as large as the relative error.
</p>
<p>
Special care needs to be taken when one value is zero: we could either take
the absolute error in this case (but that's cheating as the absolute error
is likely to be very small), or we could assign a value of either 1 or infinity
to the relative error in this special case. In the test cases for the special
functions in this library, everything below a threshold is regarded as "effectively
zero", otherwise the relative error is assigned the value of 1 if only
one of the terms is zero. The threshold is currently set at <code class="computeroutput"><span class="identifier">std</span><span class="special">::</span><span class="identifier">numeric_limits</span><span class="special"><>::</span><span class="identifier">min</span><span class="special">()</span></code>: in other words all denormalised numbers
are regarded as a zero.
</p>
<p>
All the test programs calculate <span class="emphasis"><em>quantized relative error</em></span>,
whereas the graphs in this manual are produced with the <span class="emphasis"><em>actual
error</em></span>. The difference is as follows: in the test programs, the
test data is rounded to the target real type under test when the program
is compiled, so the error observed will then be a whole number of <span class="emphasis"><em>units
in the last place</em></span> either rounded up from the actual error, or
rounded down (possibly to zero). In contrast the <span class="emphasis"><em>true error</em></span>
is obtained by extending the precision of the calculated value, and then
comparing to the actual value: in this case the calculated error may be some
fraction of <span class="emphasis"><em>units in the last place</em></span>.
</p>
<p>
Note that throughout this manual and the test programs the relative error
is usually quoted in units of epsilon. However, remember that <span class="emphasis"><em>units
in the last place</em></span> more accurately reflect the number of contaminated
digits, and that relative error can <span class="emphasis"><em>"wobble"</em></span>
by a factor of 2 compared to <span class="emphasis"><em>units in the last place</em></span>.
In other words: two implementations of the same function, whose maximum relative
errors differ by a factor of 2, can actually be accurate to the same number
of binary digits. You have been warned!
</p>
<a name="zero_error"></a><h5>
<a name="math_toolkit.backgrounders.relative_error.h0"></a>
<span><a name="math_toolkit.backgrounders.relative_error.the_impossibility_of_zero_error"></a></span><a class="link" href="relative_error.html#math_toolkit.backgrounders.relative_error.the_impossibility_of_zero_error">The
Impossibility of Zero Error</a>
</h5>
<p>
For many of the functions in this library, it is assumed that the error is
"effectively zero" if the computation can be done with a number
of guard digits. However it should be remembered that if the result is a
<span class="emphasis"><em>transcendental number</em></span> then as a point of principle we
can never be sure that the result is accurate to more than 1 ulp. This is
an example of <span class="emphasis"><em>the table makers dilemma</em></span>: consider what
happens if the first guard digit is a one, and the remaining guard digits
are all zero. Do we have a tie or not? Since the only thing we can tell about
a transcendental number is that its digits have no particular pattern, we
can never tell if we have a tie, no matter how many guard digits we have.
Therefore, we can never be completely sure that the result has been rounded
in the right direction. Of course, transcendental numbers that just happen
to be a tie - for however many guard digits we have - are extremely rare,
and get rarer the more guard digits we have, but even so....
</p>
<p>
Refer to the classic text <a href="http://docs.sun.com/source/806-3568/ncg_goldberg.html" target="_top">What
Every Computer Scientist Should Know About Floating-Point Arithmetic</a>
for more information.
</p>
</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 © 2006-2010 John Maddock, Paul A. Bristow, Hubert Holin, Xiaogang Zhang, Bruno
Lalande, Johan Råde, Gautam Sewani, Thijs van den Berg and Benjamin Sobotta<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="implementation.html"><img src="../../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../backgrounders.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="lanczos.html"><img src="../../../../../../../doc/src/images/next.png" alt="Next"></a>
</div>
</body>
</html>
|
