C++ for Scientists - Technische Universität Dresden

14 CHAPTER 1. GOOD AND BAD SCIENTIFIC SOFTWARE
without the comments? We would easily catch where the variables representing q, A, and p
are used but to see that this is a matrix vector product will take a closer look and a good
understanding how the matrix is stored.
This leads us to the second problem: the implementation commits to many technical details
and only works in precisely this context. Algorithm 1 only requires that matrix A is symmetric
positive-definite but it does not demand a certain storage scheme. There are many other sparse
matrix formats that we can all use in the CG method but not with this implementation. The
matrix format is not the only detail the code commits to. What if we want to compute in lower
(float) or higher precision (long double)? Or solve a complex linear system? For every such
new CG application, we need a new implementation. Needless to say that running on parallel
computers or exploring GPGPU (General-Purpose Graphic Processing Units) acceleration
needs reimplementations as well. Much worse, every combination of the above needs a new
implementation.
Some of the readers might think: “It is only one function of 20–30 lines. Rewriting this little
function, how much work can this be. And we do not introduce new matrix formats or computer
architectures every month.” Certainly true but in some sense it is putting the cart before
the horse. Because of such inflexible and detail-obsessed programming style, many scientific
applications grew into the 100,000s and millions of lines of code. Once an application or library
reached such a monstruous size, it is very arduous modifying features of the software and only
rarely done. The road to success is starting scientific software from a higher level of abstraction
from the beginning, even if it is more work initially.
The last major disadvantage is how error-prone it is. All arguments are given as pointers and
the size of the underlying arrays is given as an extra argument. We as programmer of function
cg can only hope that the caller did everything right because we have no way to verify it. If
the user does not allocate enough memory (or does not allocate at all) the execution will crash
at some more or less random position or even worse, will generate some nonsensical results
because data and software can be randomly owerwritten. Good programmers must avoid such
fragile interfaces because the slightest mistake can have catastrophic consequences and the
program errors are extremely difficult to find. Unfortunately, even recently released and widely
used software is written in this manner, either for backward-compatibility to C and Fortran or
because it is written in one of these two languages. In fact, the implementation above is C and
not C ++. If this is way you love software, you probably will not like this script.
So much about software we do not like. In Listing 1.2 we show how scientific software could
look like.
// This source is part of MTL4
#include
#include
template < typename LinearOperator, typename HilbertSpaceX, typename HilbertSpaceB,
typename Preconditioner, typename Iteration >
int conjugate gradient(const LinearOperator& A, HilbertSpaceX& x, const HilbertSpaceB& b,
const Preconditioner& L, Iteration& iter)
{
typedef HilbertSpaceX Vector;
typedef typename mtl::Collection::value type Scalar;
Scalar rho(0), rho 1(0), alpha(0);