Scor­pio News

What it does is start with the number 1, and carry out a string of functions on it, which are intended to get back to the same value they started with, i.e. 1. This is then incremented, and the process repeated. So, if the computer is working to absolutely exact values in all its calculations, the final result will be 2500.

I ran this program using various Hisoft Pascals, and used a 20 year old Seiko automatic watch to time it. The results were as follows:–

Now all of these are faster than the times quoted by P D Coker in issue 1, and the HP5 time, using that lovely floating point board, is miles faster than any of the competition. This pleases me immensely. But I know what you are thinking, “Those answers are miles out!”. Well, Paddy Coker did ask if anyone could explain the apparently awful result the Hisoft Pascals give on this benchmark, and I’am volunteering as I have done the Open University course M351, Numerical Computation (and I even passed!).

The program carries out 6x2500 = 15,000 floating point calculations, one after another. Any inaccuracy caused by the need to truncate the values to fit into the space allocated to a real variable will obviously mount up considerably over such a sequence of calculations. This tendency to reduce slightly the value of each result that will not fit in a real probably accounts for a large part of the deficit.

Clearly, anyone who is still awake will be wondering why all the other languages get so much closer to the “right” answer. They might feel that I am trying desperately to defend a compiler that I like, with no justification. In an attempt to find out what was at the root of the matter, I asked Hisoft how their tan and arctan functions worked. I thought they might use a Taylor series, or some such idea. I had, by fiddling about with the original program, discovered that almost all the inaccuracy was being created by the tan and arctan functions of HP4. Unlike every other software firm I have ever written to, Hisoft answered my enquiry. I quote…

“As you probably realise the Trig routines for the Pascal were written rather a long time ago. I think it was in March 1981! They were originally written in Pascal and then hand coded into assembler attempting to make the controlling code as tight as possible and with speed rather than space in mind. I can’t actually remember whether they were written on a disk machine or on cassette. But either way the original Pascal source has long since disappeared. The algorithms used are mainly continuous fractions having divided the 0-90 degree range into a number of sections. Look at the assembler source; it doesn’t make much sense since the only comments refer to the variables and constants from the Pascal version. The TAN function seems to use two entirely separate algorithms depending on the input value. One of the constants had to be fudged to avoid discontinuity which sadly leads to inaccuracy near 90. The algorithms were developed from a book published by HMSO in 1959 when speed of the algorithms used was really important. I can’t remember its title but I’m pretty sure it involves ‘digital computers’.”

I would be prepared to bet that the “inaccuracy near 90” is the main reason for the bad result. P D Coker got using HP4. Calculations carried out sensibly will give good results, while 15000 floating point operations in a row on a variable will indicate a silly program, and will give silly results. All the usual remarks about the usefulness or otherwise of benchmark programs are given even more emphasis by this result. I just wonder how the other languages gave so