80-Bus News

point of view, the shorter the polynomial, the faster it can be evaluated. For those who wish to pursue matters further various books can be found covering the topic. One fairly comprehensive book I have encountered is {1].

So point one is that derived functions such as “^” LOG, EXP, etc are written for the general case and have approximate results. (They may be accurate, but not necessarily exact.) They do not recognise specific cases (such as the exponent in a “^” expression being a small integer) and do not adjust their algorithms accordingly. This means that the instruction in line 60 (IF A=B THEN…) is almost certainly going to be false. If A=2 and B=1.999999999..... then they are not equal in the eyes of the computer although an engineer would happily accept them as such. (Mind you a Scientist may not, but that leads on to the old joke…) Therefore line 60 has to be rephrased as – IF A EQUALS B FOR ALL PRACTICAL PURPOSES THEN .... This can best be done by coding it as IF ABS(A-B)<1E-4 THEN.... Here we have said if the two values are within 1/10,000 of each other then take them as equal. After making this change the program above will run successfully.

Alternatively the program can be recoded to make the calculation more accurate. By recoding line 40 as … N1*N1*N1 + N2*N2.... we replace the approximation by an accurate calculation. (Accurate in this case as we are dealing with reasonably sized Integers. In other circumstances – e.g. N1 etc being REAL numbers like 2.345 and 7.916 – there would be rounding errors and possible dynamic range problems affecting the accuracy of the result.) This change also has the side effect of speeding up the program as the two multiplications are faster than the ^ function. In making this change to line 40, line 60 can be left as IF A=B… (but remember the caveat above).

Point 2: Binary Arithmetic

While we are on the topic of computer accuracy I’ll just mention one other point. Computers that use binary arithmetic cannot hold most decimal fractions accurately. (e.g. 2.67 might be held as “a number very close to 2.67’.) This is why any serious financial program always uses BCD (Binary Coded Decimal) arithmetic – where 2.67 IS 2.67 – rather than pure binary arithmetic. That way the books generally balance exactly rather than approximately as the arithmetic exactly matches the human ‘pencil & paper’ mode. Details of BCD algorithms can be found in [2].

Software Testing

The example above highlights another important point that we are all frequently guilty of, and that is inadequate testing of programs. This program is not perhaps the best example as it does not process any external data in order to produce its result. The important point though is that Phil Dunglinson knew what the program should do (in its present form) and when the correct results didn’t emerge he knew there was a bug to find. Software testing is an art. (Think of the unlimited character combinations possible in the source input file for an assembler or compiler.) There are various books on the topic that you can read if you are interested [3][4]. I don’t intend to cover software testing here, but one thing to remember is that any program that processes data, as well as producing correct output from correct input, must not accept incorrect input without complaining, or crash when presented with the unexpected.

Just to give a few examples of what I’ve encountered: First a minor bug illustrating what can happen to a program presented with the unexpected. With C/80 version 2.0 the compiler carried on compiling a source file past the end-of-file marker if the file ended in a TAB character rather than the usual CR/LF pair. (Easy enough to end up with a TAB if you use an on-screen editor.)