6.6 Testing Code
151
6.6.2 Proper Test Procedures
There are three serious ways to test the implementation of numerical methods via
unit tests:
1. Comparing with hand-computed results. Relevant for problems with few arithmetic operations, i.e., small n.
2. Solving a problem without numerical errors. We know, for example, that the
trapezoidal rule must be exact for linear integrand functions. The error produced
by the program must then be zero (to machine precision).
3. Demonstrating correct convergence rates. When exact errors can be computed,
a strong test is to let n grow and see if the error approaches zero as fast as theory
predicts. As stated previously, for the trapezoidal and midpoint rules it is known
that the error depends on n as n −2 when n → ∞.
Remark
When testing code, we usually choose computational problems for which
the exact solution is known. This is obviously a good idea, since it allows
the quality of approximate numerical answers to be judged. Do not forget,
however, that the exact solution is available because we deliberately chose
a problem with known exact solution. When we have finished testing (and
probably fixing) the code, our belief is that the code will work also for
problems with unknown exact solutions. Our strategy then, is to trust the
approximate answer from our code.
Hand-Computed Results Let us use two trapezoids and compute the integral
1
0 v(t)dt, where v(t) = 3t 2 e t 3 :
h
(v(0) + v(0.5))
2
+ h
(v(0.5) + v(1))
2
= 2.463642041244344,
when h = 0.5 is the width of each trapezoid. Running the program gives exactly the
same result.
Note that the exact solution is not involved here. We simply carry out the
numerical algorithm by hand, “independent” from the code. We should of course
get agreement between these hand calculations and program output when the same
n is used. However, assuming we do get agreement, that numerical answer may still
differ substantially from the exact solution to the problem. That is of no concern in
this test, as the aim is not to get as good an answer as possible (potentially achieved
with a large n), but rather to check in a simple manner whether the algorithm “seems
to be” correctly implemented.
Solving a Problem Without Numerical Errors The best unit tests for numerical
algorithms involve mathematical problems where we know the numerical result
beforehand. For these unit tests, we choose problems that fulfill two criteria. One
151
6.6.2 Proper Test Procedures
There are three serious ways to test the implementation of numerical methods via
unit tests:
1. Comparing with hand-computed results. Relevant for problems with few arithmetic operations, i.e., small n.
2. Solving a problem without numerical errors. We know, for example, that the
trapezoidal rule must be exact for linear integrand functions. The error produced
by the program must then be zero (to machine precision).
3. Demonstrating correct convergence rates. When exact errors can be computed,
a strong test is to let n grow and see if the error approaches zero as fast as theory
predicts. As stated previously, for the trapezoidal and midpoint rules it is known
that the error depends on n as n −2 when n → ∞.
Remark
When testing code, we usually choose computational problems for which
the exact solution is known. This is obviously a good idea, since it allows
the quality of approximate numerical answers to be judged. Do not forget,
however, that the exact solution is available because we deliberately chose
a problem with known exact solution. When we have finished testing (and
probably fixing) the code, our belief is that the code will work also for
problems with unknown exact solutions. Our strategy then, is to trust the
approximate answer from our code.
Hand-Computed Results Let us use two trapezoids and compute the integral
1
0 v(t)dt, where v(t) = 3t 2 e t 3 :
h
(v(0) + v(0.5))
2
+ h
(v(0.5) + v(1))
2
= 2.463642041244344,
when h = 0.5 is the width of each trapezoid. Running the program gives exactly the
same result.
Note that the exact solution is not involved here. We simply carry out the
numerical algorithm by hand, “independent” from the code. We should of course
get agreement between these hand calculations and program output when the same
n is used. However, assuming we do get agreement, that numerical answer may still
differ substantially from the exact solution to the problem. That is of no concern in
this test, as the aim is not to get as good an answer as possible (potentially achieved
with a large n), but rather to check in a simple manner whether the algorithm “seems
to be” correctly implemented.
Solving a Problem Without Numerical Errors The best unit tests for numerical
algorithms involve mathematical problems where we know the numerical result
beforehand. For these unit tests, we choose problems that fulfill two criteria. One