1[section:relative_error Relative Error] 2 3Given an actual value /a/ and a found value /v/ the relative error can be 4calculated from: 5 6[equation error2] 7 8However the test programs in the library use the symmetrical form: 9 10[equation error1] 11 12which measures /relative difference/ and happens to be less error 13prone in use since we don't have to worry which value is the "true" 14result, and which is the experimental one. It guarantees to return a value 15at least as large as the relative error. 16 17Special care needs to be taken when one value is zero: we could either take the 18absolute error in this case (but that's cheating as the absolute error is likely 19to be very small), or we could assign a value of either 1 or infinity to the 20relative error in this special case. In the test cases for the special functions 21in this library, everything below a threshold is regarded as "effectively zero", 22otherwise the relative error is assigned the value of 1 if only one of the terms 23is zero. The threshold is currently set at `std::numeric_limits<>::min()`: 24in other words all denormalised numbers are regarded as a zero. 25 26All the test programs calculate /quantized relative error/, whereas the graphs 27in this manual are produced with the /actual error/. The difference is as 28follows: in the test programs, the test data is rounded to the target real type 29under test when the program is compiled, 30so the error observed will then be a whole number of /units in the last place/ 31either rounded up from the actual error, or rounded down (possibly to zero). 32In contrast the /true error/ is obtained by extending 33the precision of the calculated value, and then comparing to the actual value: 34in this case the calculated error may be some fraction of /units in the last place/. 35 36Note that throughout this manual and the test programs the relative error is 37usually quoted in units of epsilon. However, remember that /units in the last place/ 38more accurately reflect the number of contaminated digits, and that relative 39error can /"wobble"/ by a factor of 2 compared to /units in the last place/. 40In other words: two implementations of the same function, whose 41maximum relative errors differ by a factor of 2, can actually be accurate 42to the same number of binary digits. You have been warned! 43 44[h4:zero_error The Impossibility of Zero Error] 45 46For many of the functions in this library, it is assumed that the error is 47"effectively zero" if the computation can be done with a number of guard 48digits. However it should be remembered that if the result is a 49/transcendental number/ 50then as a point of principle we can never be sure that the result is accurate 51to more than 1 ulp. This is an example of what 52[@http://en.wikipedia.org/wiki/William_Kahan] called 53[@http://en.wikipedia.org/wiki/Rounding#The_table-maker.27s_dilemma]: 54consider what happens if the first guard digit is a one, and the remaining guard digits are all zero. 55Do we have a tie or not? Since the only thing we can tell about a transcendental number 56is that its digits have no particular pattern, we can never tell if we have a tie, 57no matter how many guard digits we have. Therefore, we can never be completely sure 58that the result has been rounded in the right direction. Of course, transcendental 59numbers that just happen to be a tie - for however many guard digits we have - are 60extremely rare, and get rarer the more guard digits we have, but even so.... 61 62Refer to the classic text 63[@http://docs.sun.com/source/806-3568/ncg_goldberg.html What Every Computer Scientist Should Know About Floating-Point Arithmetic] 64for more information. 65 66[endsect][/section:relative_error Relative Error] 67 68[/ 69 Copyright 2006, 2012 John Maddock and Paul A. Bristow. 70 Distributed under the Boost Software License, Version 1.0. 71 (See accompanying file LICENSE_1_0.txt or copy at 72 http://www.boost.org/LICENSE_1_0.txt). 73] 74