Space Station Lambda

Engineering reality often confronts us with systems that can’t be modelled very well with fixed formulas.
Sometimes we don’t even know some of the system equation’s variables; think of signal noise, for example.

Enter the Kalman filtering algorithm. Given a number of observable and non-observable states, a Kalman filter tries to predict the non-observables ones.

Normally the state vectors have a dimension greater than 1, so you have to fiddle around with matrices. We once implemented the filter in Java; it was astonishingly simple, but the Java idiosyncrasy of making even the most simple code look complicated diminished this simplicity considerably. Here’s the core of it, i.e. the code minus the various “object-oriented” boilerplate methods:

public void filter(State state) throws MatrixException {
 
    setStateTransitionMatrix(delta, state.getAcceleration());
 
    x = lastX;
 
    y.setValue(0, 0, state.getPosition().getX());
    y.setValue(1, 0, state.getPosition().getY());
    y.setValue(2, 0, state.getPosition().getZ());
 
    /* PREDICT */
    x = A.multiply(x);
 
    if ((!E.isZeroMatrix()) && (R != null) && (!R.isZeroMatrix())) {
        E = ((A.multiply(E)).multiply(A.transpose())).add(Q);
        Matrix K = null;
 
        /* CORRECT */
        K = (E.multiply(B.transpose())).multiply(((B.multiply(E))
                .multiply(B.transpose()).add(R)).invert());
 
        if (!K.isZeroMatrix()) {
            x = x.add(K.multiply(y.subtract(B.multiply(x))));
            E = (I.subtract(K.multiply(B))).multiply(E);
        }
 
    }
    lastX = x;
    setState(state);
}

And now you may leave the torture chamber and take a look at an implementation in q. Beautiful!

Comments(0)

In the first section of his essay Engineering and Star Trek Michael Wong does a pretty good job of pointing out the differences between science and engineering (after that he moves on to rant about Star Trek’s engineering blunders, but we shall not concern ourselves with that here).

Michael writes:

Engineering is more difficult than science in some ways, and it is also easier in some ways. Scientists need to understand their theories in much more detail than engineers do, and they require stronger abstract thinking skills. They must be able to explain the principles behind every idea, and they don’t have the luxury of relying on “rules of thumb” and empirical correlations when in doubt. While engineers can concentrate on the applications of a theory, scientists must study its derivation from first principles. However, scientists do catch a break in three crucial areas: time, complexity, and consequence.

Time because of the temporal constraints placed upon projects: the competition can’t be allowed to finish it earlier, or a solution is needed urgently for an already running projects.

Complexity because of the environment the project is running in. The operating system’s peculiarities must be adhered to, interfaces to other vendor’s software must be handled, emergencies (hardware failure, malicious software) taken into account.

Consequence because the consequences of failure are often more dire. Computer science is the most important field today, pervading everything from hospitals to household devices. Well, you don’t need to imagine what will happen if one of those systems has a serious failure.

Enter Edsger Dijkstra. The famous computer scientist’s writing On the cruelty of really teaching computing science scorns the engineering labeling of all software development issues:

As economics is known as “The Miserable Science”, software engineering should be known as “The Doomed Discipline”, doomed because it cannot even approach its goal since its goal is self-contradictory.

It wouldn’t be so bad if it would limit itself on issues of Computer Science, but that’s not the case. And he doesn’t seem to be exactly rational about it, as can be seen in his usage of logical fallacies (biased sample, spotlight, appeal to ridicule), like in the following passage:

But it [the engineering label] is totally symbolic, as one of the US computer manufacturers proved a few years ago when it hired, one night, hundreds of new “software engineers” by the simple device of elevating all its programmers to that exalting rank. So much for that term.

There are many more such rhetorical devices all over the paper, and a commentary pointing them all out would probably be a good exercise. But since it’s obviously a polemic pamphlet, let us turn away from nitpicking and look at the guts of his arguments.

To begin with:

Unfathomed misunderstanding is further revealed by the term “software maintenance”, as a result of which many people continue to believe that programs –and even programming languages themselves– are subject to wear and tear. Your car needs maintenance too, doesn’t it? Famous is the story of the oil company that believed that its PASCAL programs did not last as long as its FORTRAN programs “because PASCAL was not maintained”.

My dear Edsger, programs are subject to wear and tear. If software necessary to run a program (e.g. compiler, interpreter, external library, operating system) or the software itself is not maintained, it will severe its ties with the future with time. Because the environment is not static (see “Complexity” above), a program needs to be changed in regular intervals to keep up with the changes in its surroundings.

Let’s get to the next:

[The programmer] has to derive that formula, he has to derive that program. We know of only one reliable way of doing that, viz. by means of symbol manipulation.

Who’s using a theorem prover to derive his latest database report program? Hands up. I am not; if I tried to do so, I will have a provably formally correct program at the end of the process. Unfortunately, a few months or years will have passed since I have begun, and the program’s environment has radically changed, and with it the assumptions that were used in the derivation of the program.

Now let us put the crown on our pamphlet and build an ivory tower by attacking “all soft sciences for which computing now acts as some sort of interdisciplinary haven”. I don’t know what to say in reply to that. Does he want to shut off all other disciplines from the usefulness of computer programs?

Let’s end the slaughtering here and see whether we can come to a sensible bottom line. Dijkstras paper is a good one, if read carefully: Computer Science is a vital part of good software development, and formal methods are a valuable tool one should not neglect. But let us not deny engineering, but let it have its place beside science, like it has in many other disciplines.

Simply put:

Good software engineering is a solid engineering discipline grown from the soil of computer science.

Comments(3)