{VERSION 4 0 "IBM INTEL NT" "4.0" }
{USTYLETAB {CSTYLE "Maple Input" -1 0 "Courier" 0 1 255 0 0 1 0 1 0 0 
1 0 0 0 0 1 }{CSTYLE "2D Math" -1 2 "Times" 0 1 0 0 0 0 0 0 2 0 0 0 0 
0 0 1 }{CSTYLE "Hyperlink" -1 17 "" 0 1 0 128 128 1 0 0 1 0 0 0 0 0 0 
1 }{CSTYLE "2D Comment" 2 18 "" 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 }
{CSTYLE "2D Output" 2 20 "" 0 1 0 0 255 1 0 0 0 0 0 0 0 0 0 1 }
{CSTYLE "" 0 21 "" 0 1 0 0 0 1 0 0 0 0 2 0 0 0 0 1 }{CSTYLE "Help Head
ing" -1 26 "" 1 14 0 0 0 0 0 1 0 0 0 0 0 0 0 1 }{PSTYLE "Normal" -1 0 
1 {CSTYLE "" -1 -1 "" 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 }0 0 0 -1 -1 -1 
0 0 0 0 0 0 -1 0 }{PSTYLE "Maple Output" 0 11 1 {CSTYLE "" -1 -1 "" 0 
1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 }3 3 0 -1 -1 -1 0 0 0 0 0 0 -1 0 }
{PSTYLE "" 11 12 1 {CSTYLE "" -1 -1 "" 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 
1 }1 0 0 -1 -1 -1 0 0 0 0 0 0 -1 0 }}
{SECT 0 {SECT 0 {PARA 0 "" 0 "" {TEXT 26 8 "Advice: " }{TEXT -1 14 "Ro
undoff error" }}{PARA 0 "" 0 "" {TEXT -1 0 "" }}{PARA 0 "" 0 "" {TEXT 
-1 302 "\"Real\" numbers are generally represented in computers using \+
 floating-point arithmetic, which is similar to so-called \"scientific
 notation\".  While most computers use a base-2 system in their \"hard
ware floats\", Maple uses base 10.  Thus a nonzero floating-point numb
er could be represented in the form " }{MPLTEXT 0 21 15 "(+ or -) r*10
^k" }{TEXT -1 7 " where " }{XPPEDIT 18 0 "k" "6#%\"kG" }{TEXT -1 34 ",
 the exponent, is an integer and " }{XPPEDIT 18 0 "r" "6#%\"rG" }
{TEXT -1 35 ", the mantissa, is in the interval " }{XPPEDIT 18 0 "0.1 \+
<= r *`<`* 1" "6#1$\"\"\"!\"\"*(%\"rGF%%\"<GF%F%F%" }{TEXT -1 21 " and
 has some number " }{XPPEDIT 18 0 "d" "6#%\"dG" }{TEXT -1 79 " of deci
mal digits.  Actually Maple's internal representation of the number is
 " }{MPLTEXT 0 21 10 "Float(a,b)" }{TEXT -1 7 " where " }{XPPEDIT 18 
0 "a = r*10^d" "6#/%\"aG*&%\"rG\"\"\")\"#5%\"dGF'" }{TEXT -1 5 " and \+
" }{XPPEDIT 18 0 "b=k-d" "6#/%\"bG,&%\"kG\"\"\"%\"dG!\"\"" }{TEXT -1 
77 " are integers.  If the number is produced by floating-point arithm
etic, then " }{XPPEDIT 18 0 "d" "6#%\"dG" }{TEXT -1 50 " is at most th
e value of the environment variable " }{MPLTEXT 0 21 6 "Digits" }
{TEXT -1 14 " at that time." }}{PARA 0 "" 0 "" {TEXT -1 0 "" }}{PARA 
0 "" 0 "" {TEXT -1 95 "Roundoff error is caused by the fact that numbe
rs are generally not representable exactly with " }{MPLTEXT 0 21 6 "Di
gits" }{TEXT -1 334 " digits, and thus must be approximated by numbers
 that are represented in this way.  The procedure that is used, known \+
as rounding, determines the closest number that can be represented.  I
n particular, the result of an arithmetic operation on floating-point \+
numbers generally requires rounding.  Suppose, for example, you were u
sing " }{MPLTEXT 0 21 8 "Digits=4" }{TEXT -1 29 ", and you wanted to m
ultiply " }{XPPEDIT 18 0 "pi" "6#%#piG" }{TEXT -1 29 " (represented to
 4 digits as " }{MPLTEXT 0 21 10 ".3142*10^1" }{TEXT -1 12 ") by 76.54
 (" }{MPLTEXT 0 21 10 ".7654*10^2" }{TEXT -1 18 ").  You calculate " }
{MPLTEXT 0 21 21 ".3142*.7654=.24048868" }{TEXT -1 42 ", and round thi
s to the four-digit number " }{MPLTEXT 0 21 5 ".2405" }{TEXT -1 69 ". \+
 Thus the result, after taking care of the powers of 10, is 240.5 (" }
{MPLTEXT 0 21 10 ".2405*10^3" }{TEXT -1 2 ")." }}{EXCHG {PARA 0 "> " 
0 "" {MPLTEXT 1 0 28 "Digits:= 4: evalf(Pi*76.54);" }}{PARA 11 "" 1 "
" {XPPMATH 20 "6#$\"%0C!\"\"" }}}{PARA 0 "" 0 "" {TEXT -1 476 "Maple's
 built-in functions are also subject to roundoff error when they opera
te on floating-point numbers.  In most cases what is computed is an ap
proximation to the function (using a few more digits than Digits), and
 then the result is rounded.  This usually results in the correct roun
ded value of the function, but once in a while it may be off by a digi
t or two.  In the example below, the correct value with Digits=14 woul
d end in 27, but the computed value ends in 31.  " }}{EXCHG {PARA 0 ">
 " 0 "" {MPLTEXT 1 0 40 "x := 1.5707963267949: \nevalf(tan(x),14);" }}
{PARA 11 "" 1 "" {XPPMATH 20 "6#$!/J`&>2z&H\"\"\"" }}}{EXCHG {PARA 0 "
> " 0 "" {MPLTEXT 1 0 30 "evalf(tan(x),20); evalf(%,14);" }}{PARA 11 "
" 1 "" {XPPMATH 20 "6#$!5x1PF`&>2z&H!\"&" }}{PARA 11 "" 1 "" {XPPMATH 
20 "6#$!/F`&>2z&H\"\"\"" }}}{PARA 0 "" 0 "" {TEXT -1 361 " The error i
n a calculation can be measured in two ways: the absolute error is the
 magnitude of the difference between the true value and the approximat
ion, while the relative error is the absolute error divided by the mag
nitude of the true value.  In many cases, the relative error is the mo
re useful (of course, it is not much use when the true value is 0).  \+
" }}{PARA 0 "" 0 "" {TEXT -1 0 "" }}{PARA 0 "" 0 "" {TEXT -1 215 "Mult
iplication and division do not cause too many problems of accuracy, be
cause they have little effect on relative error.  For addition and sub
traction, on the other hand, there are two important problems to note.
\n" }}{PARA 0 "" 0 "" {TEXT -1 257 "The first is that when two numbers
 of very different magnitudes are added, many of the digits of the sma
ller one will have no effect on the result.  This means that calculati
ng a sum of very many, very small quantities can lead to very inaccura
te results.  " }}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 34 "Digits:= 4:
 add(4./9000,i=1..900);" }}{PARA 11 "" 1 "" {XPPMATH 20 "6#$\"%#p$!\"%
" }}}{PARA 0 "" 0 "" {TEXT -1 40 "The correct result, of course, would
 be " }{XPPEDIT 18 0 "0.4" "6#$\"\"%!\"\"" }{TEXT -1 77 ".  But when t
he total gets to .1, each addition of 4./9000 = .000444... with " }
{MPLTEXT 0 21 10 "Digits = 4" }{TEXT -1 127 " has only the effect of a
dding .0004.  Even more strikingly, when the total gets to 1, further \+
additions have no effect at all." }}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 
1 0 23 "add(4./9000,i=1..9000);" }}{PARA 11 "" 1 "" {XPPMATH 20 "6#$\"
%+5!\"$" }}}{PARA 0 "" 0 "" {TEXT -1 133 "The second problem is that s
ubtraction of two nearly equal quantities will result in a large relat
ive error.  For example,still with " }{MPLTEXT 0 21 10 "Digits = 4" }
{TEXT -1 1 ":" }}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 12 "4.322-4.321
;" }}{PARA 11 "" 1 "" {XPPMATH 20 "6#$\"\"\"!\"$" }}}{PARA 0 "" 0 "" 
{TEXT -1 464 "This in itself is a completely correct calculation, with
 no roundoff.  But if one or both of the numbers 4.322 and 4.321 are a
pproximations for other numbers, the relative error in the difference \+
may be very large.  For example, the true values might be 4.3216 and 4
.3214 respectively, so the true difference is .0002, for a huge relati
ve error of 4.  One place where this can cause unexpected problems is \+
in the standard formula for solving a quadratic equation:\n" }
{XPPEDIT 18 0 "r[`-`] = (-b - sqrt(b^2-4*a*c))/(2*a), r[`+`] = (-b+sqr
t(b^2-4*a*c))/(2*a)" "6$/&%\"rG6#%\"-G*&,&%\"bG!\"\"-%%sqrtG6#,&*$F*\"
\"#\"\"\"*(\"\"%F2%\"aGF2%\"cGF2F+F+F2*&F1F2F5F2F+/&F%6#%\"+G*&,&F*F+-
F-6#,&*$F*F1F2*(F4F2F5F2F6F2F+F2F2*&F1F2F5F2F+" }}{PARA 0 "" 0 "" 
{TEXT -1 8 "Suppose " }{XPPEDIT 18 0 "b" "6#%\"bG" }{TEXT -1 36 " is p
ositive, and large compared to " }{XPPEDIT 18 0 "a" "6#%\"aG" }{TEXT 
-1 5 " and " }{XPPEDIT 18 0 "c" "6#%\"cG" }{TEXT -1 8 ".  Then " }
{XPPEDIT 18 0 "sqrt(b^2 -4* a* c)" "6#-%%sqrtG6#,&*$%\"bG\"\"#\"\"\"*(
\"\"%F*%\"aGF*%\"cGF*!\"\"" }{TEXT -1 16 " will be nearly " }{XPPEDIT 
18 0 "b" "6#%\"bG" }{TEXT -1 26 ". Although it's fine for  " }
{XPPEDIT 18 0 "r[`-`]" "6#&%\"rG6#%\"-G" }{TEXT -1 55 ", the formula c
an produce a relatively very inaccurate " }{XPPEDIT 18 0 "r[`+`]" "6#&
%\"rG6#%\"+G" }{TEXT -1 20 ".  We'll try it for " }{XPPEDIT 18 0 "a=c
" "6#/%\"aG%\"cG" }{XPPEDIT 18 0 "``=1" "6#/%!G\"\"\"" }{TEXT -1 6 " a
nd  " }{XPPEDIT 18 0 "b = 130, 13000,1300000" "6%/%\"bG\"$I\"\"&+I\"\"
(++I\"" }{TEXT -1 7 "  with " }{MPLTEXT 0 21 11 "Digits = 10" }{TEXT 
-1 1 "." }}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 120 "Digits:= 10: \nr
[`-`]:= b -> (-b - sqrt(b^2-4))/2: \nr[`+`]:= b -> (-b + sqrt(b^2-4))/
2:\nblist:= [130., 13000., 1300000.]:" }}}{PARA 0 "" 0 "" {TEXT -1 25 
"Here are the results for " }{XPPEDIT 18 0 "r[`-`]" "6#&%\"rG6#%\"-G" 
}{TEXT -1 10 " at these " }{XPPEDIT 18 0 "b" "6#%\"bG" }{TEXT -1 8 " v
alues:" }}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 18 "map(r[`-`],blist);
" }}{PARA 11 "" 1 "" {XPPMATH 20 "6#7%$!+sI#**H\"!\"($!+#******H\"!\"&
$!+++++8!\"$" }}}{PARA 0 "" 0 "" {TEXT -1 6 "Using " }{MPLTEXT 0 21 6 
"fsolve" }{TEXT -1 6 " with " }{MPLTEXT 0 21 11 "Digits = 20" }{TEXT 
-1 75 " confirms that these are accurate to nearly 10 digits (the fina
l digits of " }{XPPEDIT 18 0 "r[`-`](130)" "6#-&%\"rG6#%\"-G6#\"$I\"" 
}{TEXT -1 5 " and " }{XPPEDIT 18 0 "r[`-`](13000)" "6#-&%\"rG6#%\"-G6#
\"&+I\"" }{TEXT -1 15 " are off by 1)." }}{EXCHG {PARA 0 "> " 0 "" 
{MPLTEXT 1 0 67 "Digits:= 20: map(b -> min(fsolve(t^2+b*t+1,t)),blist)
;\nDigits:= 10:" }}{PARA 12 "" 1 "" {XPPMATH 20 "6#7%$!5)Go(3PsI#**H\"
!#<$!5AE#p2B******H\"!#:$!5#p2B**********H\"!#8" }}}{PARA 0 "" 0 "" 
{TEXT -1 13 "However, the " }{XPPEDIT 18 0 "r[`+`]" "6#&%\"rG6#%\"+G" 
}{TEXT -1 46 " results are much poorer in relative accuracy." }}
{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 18 "map(r[`+`],blist);" }}{PARA 
11 "" 1 "" {XPPMATH 20 "6#7%$!'v#p(!\")$!#v!\"'$\"\"!F+" }}}{PARA 0 "
" 0 "" {TEXT -1 13 "According to " }{MPLTEXT 0 21 6 "fsolve" }{TEXT 
-1 34 ", we have five correct digits for " }{XPPEDIT 18 0 "b = 130" "6
#/%\"bG\"$I\"" }{TEXT -1 10 ", one for " }{XPPEDIT 18 0 "b = 13000" "6
#/%\"bG\"&+I\"" }{TEXT -1 14 " and none for " }{XPPEDIT 18 0 "b = 1300
000" "6#/%\"bG\"(++I\"" }{TEXT -1 1 "." }}{EXCHG {PARA 0 "> " 0 "" 
{MPLTEXT 1 0 67 "Digits:= 20: map(b -> max(fsolve(t^2+b*t+1,t)),blist)
;\nDigits:= 10:" }}{PARA 12 "" 1 "" {XPPMATH 20 "6#7%$!54K;rJ7Hw#p(!#A
$!5.T1V#yt2Bp(!#C$!5!pRC7Bp2Bp(!#E" }}}{PARA 0 "" 0 "" {TEXT -1 21 "A \+
better formula for " }{XPPEDIT 18 0 "r[`+`]" "6#&%\"rG6#%\"+G" }{TEXT 
-1 71 " in this case exploits the fact that the product of the two roo
ts is 1." }}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 35 "s:= unapply(norm
al(1/r[`-`](b)),b);" }}{PARA 11 "" 1 "" {XPPMATH 20 "6#>%\"sGR6#%\"bG6
\"6$%)operatorG%&arrowGF(,$*&\"\"\"F.,&9$F.*$-%%sqrtG6#,&*$)F0\"\"#F.F
.\"\"%!\"\"F.F.F:!\"#F(F(F(" }}}{EXCHG {PARA 0 "> " 0 "" {MPLTEXT 1 0 
13 "map(s,blist);" }}{PARA 11 "" 1 "" {XPPMATH 20 "6#7%$!+7Hw#p(!#7$!+
OxI#p(!#9$!+#p2Bp(!#;" }}}{PARA 0 "" 0 "" {TEXT -1 119 "There is no su
btraction of nearly equal quantities here, and the results have 10, 9 \+
and 10 correct digits respectively." }}}{SECT 0 {PARA 0 "" 0 "" {TEXT 
26 9 "See also:" }{TEXT -1 1 " " }{HYPERLNK 17 "Automatic simplificati
on and evalf" 2 "Automatic_simplification_and_evalf" "" }{TEXT -1 2 ",
 " }{HYPERLNK 17 "Digits" 2 "Digits" "" }{TEXT -1 2 ", " }{HYPERLNK 
17 "evalf" 2 "evalf" "" }{TEXT -1 2 ", " }{HYPERLNK 17 "Exact vs. floa
ting-point computations" 2 "Exact_vs._floating-point_computations" "" 
}{TEXT -1 2 ", " }{HYPERLNK 17 "Forcing floating-point arithmetic" 2 "
Forcing_floating-point_arithmetic" "" }{TEXT -1 2 ", " }{HYPERLNK 17 "
The meaning of Digits" 2 "The_meaning_of_Digits" "" }}}{SECT 0 {PARA 
0 "" 0 "" {TEXT 26 24 "Maple Advisor Database, " }{TEXT -1 15 " R. Isr
ael 1997" }}}}{MARK "0 32 0" 0 }{VIEWOPTS 1 1 0 1 1 1803 1 1 1 1 }
{PAGENUMBERS 0 1 2 33 1 1 }