For this purpose the computer is permitted to stow the number 49 away somewhere, and is instructed to compare the contents of the index register after each operation with the stored 49. An instruction is needed for this:
You can almost hear the instruction asking, with raised eyebrows; "Haven't you reached that 49 yet?"
Now you should know that the jump instruction we were talking about a short time ago, the "S, ≠" is what is called a "conditional jump instruction." It does not allow the computer to jump back regardless of the conditions in the program, but only just as long as the answer to the questioning instruction "I 8 ? 0049" is a "No!" If the answer is "Yes!" when the content of the index register has reached 49, the instruction gives no more commands to jump. It then allows further calculation to be done without further ado - though very little in fact happens right away, merely the final command, which we already know:
Our program, reading from front to back now looks like this:
| = > I 8
= > A
Confronted with this program, our programmer-in-chief would have no more objections to raise. It needs only seven commands, in other words no more than seven storage locations - storage cells - instead of the 51 we formerly proposed, and that is quite an advantage. Yes, with the same number of program instructions it is possible to add up not only 50 numbers but 200 or 6000; all that is needed is to set the reference number at 199 or 5999 instead of at 49. With this program, any sum whatever that the computer is ever likely to have to add up, can be dealt with - provided that care has been taken beforehand to see that the numbers to be added are to be found in storage cells 1001 and up. If the computer frequently has to do additions, the adding program can be left in the program storages for months, or forever. Why not? It is short and takes up very little room.
Compared with the old and lengthier program, however, our new one has one drawback: it is slower. That is understandable: a "cyclic" or "selftriggering" program (with built-in jumps) demands a relatively large number of "logical instructions" to bring about the comparison, the jump, etc. - in addition to the "arithmetical instructions" which do nothing but count. A "linear program" without jumps consists of practically nothing but arithmetical instructions, and moreover it is carried out more quickly.
To add our 50 numbers, we first of all worked out a linear program. It needs about 0.20 milliseconds (2 ten-thousandths of a second) for each instruction; the "Stop!" instruction will use only 0.15 milliseconds. The total time needed for the addition would thus be 50 times 0.20 plus 0.15 milliseconds.
Ten milliseconds are a hundredth of a second. If you have a camera, you will have some notion of just how fast that is. With an exposure of ten milliseconds you could take unblurred photographs of cars racing.
Our cyclic program demands a little more time. A cycle (from the third to the sixth instruction) requires about 0.8 milliseconds. The first two instructions and the "Stop!" instruction together need about 0.5 milliseconds. The whole program thus requires 49 times 0.8 plus 0.5, or 39.7 milliseconds - about a fortieth of a second in all.
Now it is more or less immaterial for people like us whether anyone needs a fortieth or a hundredth of a second to add up 50 numbers. The fact that it can be done anywhere near this fast at all impresses us enough; to bother about a fraction of a second more or less either way is mere hair-splitting. But a photographer knows that there is indeed quite a substantial difference between a fortieth and a hundredth of a second. For a programmer, the difference is a substantial one too, for he does not as a rule restrict himself to the adding up of 50 numbers - he works on far more extensive programs. When it looks as if a whole program may take a week to run its course, and very easily twice as long if the program is set up differently, it obviously pays to give the matter a little thought.