Writing Scientific Software: A Guide to Good Style

by Suely Oliveira, David E. Stewart

The core of scientific computing is designing, writing, testing, debugging and modifying numerical software for application to a vast range of areas: from graphics, meteorology and chemistry to engineering, biology and finance. Scientists, engineers and computer scientists need to write good code, for speed, clarity, flexibility and ease of re-use. Oliveira and Stewart's style guide for numerical software points out good practices to follow, and pitfalls to avoid. By following their advice, readers will learn how to write efficient software, and how to test it for bugs, accuracy and performance. Techniques are explained with a variety of programming languages, and illustrated with two extensive design examples, one in Fortran 90 and one in C++: other examples in C, C++, Fortran 90 and Java are scattered throughout the book. This manual of scientific computing style will be an essential addition to the bookshelf and lab of everyone who writes numerical software.

Genres: Programming

316 pages, Paperback

First published January 1, 2006

Reviews

[Koen Crolla · Rating 3 out of 5]

Well-intended, but largely useless. This book reads like the field notes of someone who isn't a full-time programmer, but rather is in a field which occasionally requires some light programming on the side; they haven't kept up with technologies or read anything about how the things they use actually do work, but over the years have accumulated a long list of perceived pitfalls and tricks, without necessarily understanding what makes them possible. Perhaps they spent some time with Google (or Altavista, which they actually suggest as a viable alternative search engine at one point; this book came out in 2006) to clean it up, but they aren't knowledgeable enough to write a book like this.

It's written by people stuck in the echo chamber of scientific computing (more specifically numerical algorithms), so naturally most code samples are in Fortran. They make a good effort with C (C99, to be precise), but fortunately, the C++ and Java mentioned on the back cover are largely consigned to a single extended example at the end of the book and the occasional offhand mention, respectively. Also unsurprisingly, and fortunately, they also mostly focus on Unix systems; sadly, though, they approach them with a cavalier ignorance that comes from multiple decades of use and a profound unwillingness to believe anything could have changed in that time; it's not the ignorance of a Ubuntu user, who believes that Ubuntu is Linux and Linux is Unix, but rather of an AIX user: they've heard of this Linux thing, but assume it's a fad with a userbase much smaller than their trusty home system, and that it behaves exactly the same — or if not, that this is a bug that should not be acknowledged because clearly it will be fixed soon.
The algorithms used as examples don't show the same sort of pig-headed obsolescense (they're algorithms, they're largely timeless), though the coding style does, to some extent.

Most of the technical details of the things they discuss are wrong to varying degree (their discussion of static versus dynamic linking, for example, is going to end in someone making a terrible fool of himself in an IRC channel at some point), and a lot of their advice is unhelpful (their discussion of regular expressions will leave people confused about their uses and the real extent of their power) or downright terrible (using an external preprocessor like m4 to manually unroll loops before compilation), but there are two sections of the book which are important and not wholly wrong.

The first is the second chapter of the first part, which deals with the pitfalls of IEEE floating point numbers. Things like catastrophic cancellation can be counter-intuitive, utterly destructive, and very hard to debug, but a lot of programming courses just never mention it.
The second is the section discussing memory hierarchies. Too many programmers (actual programmers, even, not just scientists who do some programming on the side) are cheerfully ignorant of CPU caches, or think they don't matter, or (worse) think their compiler will magically take care of it for them. It won't. Pay attention.

That said, I'm not convinced those sections save the rest of the book. Much of it is harmless fluff, to be sure, but unless you already know about all of these things, you won't be able to tell the merely harmless from the very bad.
Really, when it comes to programming, you need to read books written by programmers. Break out of the ghetto of scientific computing, and look at what people who are doing this for real are doing. I normally hold programmers in much lower esteem than scientists, but when it comes to programming, they're probably the people you want to pay attention to.
The problem is just that programmers are usually full of shit as well. But at least they're more obvious about it.

(I will say this, though: books written in LaTeX are noticeably prettier than books written using pretty much anything else, especially when it comes to mathematical notation. The only exception is code listings, which, given that it was designed specifically for CS textbooks, is ridiculously awful. I don't know why Knuth can't get anything exactly right even once. There are good third-party libraries, but Writing Scientific Software sadly didn't use them.)

[Gus · Rating 3 out of 5]

More useful than I expected. I might re-read parts of it again.