I was a student apprentice with The English Electric Aviation from 1957 to 1962. I ended doing post-graduate studies at what is now City University and returned to Warton during the '62 summer vacation to be placed in the Mathematical Services Department, headed by John McDonnell. This may have happened because I had been doing autocode programming on a Ferranti Pegasus at college, which at the time was still a novelty.
I think it became clear to John McD fairly early on that I did not exhibit great aptitude for programming, matched in equal measure by a limited application of effort. However, when the vacation period came to an end and I decided to discontinue my post-graduate work, John was kind enough to give me a permanent position.
At the beginning, and possibly because I was only scheduled to be there a short time, I was assigned to do Alphacode programming, working directly to J McD himself. The briefs were always laid down with great care and in immaculate hand-writing. I gained from John, the impression that the arrival of the digital computer had stimulated a revival of old numerical techniques. For many years, mathematicians had pushed out the envelope to develop methods and function linearisations such that solution could be obtained using the electrical desk calculators (Monroe's, Facit's, etc) of the day. When the computer came along, it was clear that the old methods of Newton et al, when used repetitively, worked very well indeed. Being endowed with a comprehensive knowledge of modern mathematics might not be a benefit, which suited me very well. Like Manuel in Fawlty Towers, "I knew nothing."
Although the DEUCE Alphacode was somewhat limited, it did contain some functions which I think were quite powerful for a system of that time, namely the ability to integrate polynomial functions (Simpson's Rule) and to solve simultaneous differential equations (Runge Kutta). I used the latter on the modelling of re-entry vehicles and the performance of the 'Jumping Jeep' in the summer of 1962. The 'jumping' hovercraft work probably contributed to the understanding that the dynamics were not likely to be as encouraging as had been hoped, i.e. the project was soon discontinued.
This first encounter with simulation work generated an interest which has never left me since. I was disappointed to find that most compilers or interpreters (e.g. Fortran, ALGOL, Basic, etc) on the later and much more powerful computers did not have the facility to integrate differential equations like the DEUCE. (However, one day the penny dropped that it was not difficult for me to write my own Runge Kutta routine.) The downside of doing the work on the DEUCE was J McD's cardinal rule that one never took the results to a customer and asked, "do these look right?" Everything had to be checked by an independent hand calculation, a discipline which was hard then but stayed with me throughout my working career.
When it was apparent that I would be staying in the Department, I think this presented J McD and the senior guys with a dilemma. The DEUCE service had been operating since the mid 1950's but the machine was approaching the end of its days. The KDF9 was on the horizon and its arrival may even have been overdue by then. Even if I had the competence, it did not seem a good investment to go on a DEUCE machine code programming course which took a month at Kidsgrove. Only the better students seemed to complete the test piece of writing a routine to calculate the monthly repayments on a mortgage in the allotted four weeks. I could have been at it for months!
I carried on doing Alphacode work, sometimes trying to produce alternative solutions to problems which one or more of the 'heavies' was working on in machine code. I remember one case where we were trying to predict temperatures around the structure in the engine bay of the Lightning. The other chaps were using a matrix interpretive approach, one in single precision and the other in double precision. I must have used a crude integration approach. All three solutions were quite different from one another. I can still picture the pained expression on John McD's face when I announced that I thought my solution was most likely to be the correct one "because it does at least predict the highest structural temperatures on the hottest part of the engine bay". I think it was this problem that J McD then referred to Wilkinson at the NPL. The great man replied by holiday post card with the simple note, "try the substitution, u equals 1 upon x!" John found it terribly embarrassing to have overlooked a classical analytical solution but was encouraged by Wilkinson's footnote: "nonetheless, you have raised an interesting numerical problem which I will look into".
A land-mark I would claim at about this time was being possibly the first person at Warton to produce teleprinter output with plain English headings above the results. As all the serious work was being done in machine code, most of the results normally came out in binary on punched cards and were later translated into alpha-numeric on an offline printer. Warton had installed a paper tape system developed by Kirk's Liverpool University team, which could produce limited printouts online. It worked with Alphacode. I was simply repeating what I had done on the Pegasus and for a few hours it gave me some credibility as a programmer. "Have you seen what Peter has done?"
I stumbled across some anomalies between the punched card and paper tape versions of Alphacode and was asked to write a program to check out all the functions in each version. What seemed like an easy task, took some time. It led to me writing one of the first BAC manuals (we had become part of BAC by then) on the use of Alphacode, and I must still have a copy somewhere in my attic. Should be valuable one day!
In the later part of my time in Maths Services, I was assigned to work for John Halliday. I am a not sure what he had done so wrong as to draw the short straw but there was the continuing feeling that we had to prepare for the time when the KDF9 would be available. John H had been involved in matrix analysis work for a long time and wanted to explore the usefulness of approximate methods for the solution of large numbers (e.g. about 100!) of simultaneous equations. Direct inversion was not really an option on the DEUCE anyway for this size of problem. I was tasked to put together a package to use 'block successive over-relaxation' (BSOR) in a form that the block size could be easily adjusted. It all took place a long time ago but I think the idea was to iterate to a solution, using the elements close to the main diagonal (i.e. solve a series of simultaneous but smaller equations) and check the overall residuals to ensure that the solution was converging. The term 'over' meant that the relaxation factor was enhanced to accelerate the process.
This activity would have to have been carried out in machine code and, whereas I recall that I did gain some experience of machine code programming through John H, a recent phone conversation with John reminded me that the main work would have been done using the Scheme B interpretive system. What I do recall quite clearly is that during the program testing, with John looking over my shoulder, the operation failed and all the display lights went out on a number of occasions. John would do a few rechecks and then say, "I know what went wrong" and drag me back upstairs to the office to think again. Throughout my subsequent career, I have thus always lived with the fear of 'the lights going out', even today with my PC, because there is no one around who can say, "I know what went wrong". Sad case, really.
I think one of the problems we faced in the BSOR work was not being sure how good our solutions were, even using long computer runs to achieve them. This led John to suggest that we attempted a direct solution of 93 simultaneous equations to calibrate the other results. I was asked to talk to the maintenance engineer to get his view on how long the computer might run without breaking down, i.e. could we get by long enough to do a direct inversion. I seem to remember it worked but I have no idea where it all led to, because I had left before the KDF9 came on the scene for which the work was being targeted.
I was sent on an ALGOL programming course but again did not stay long enough to witness the arrival of the DEUCE 'baby ALGOL' compiler. What a challenge producing that must have been!
A number of events have stuck in my mind over the years, which may be worth recounting:
• The programmers got direct access to the computers during certain periods of the day but could often slip their jobs in at other times. This meant that there was a fairly continuous interaction with the machine and, in my case, led to the habit of 'let us see if this works'. Then came the black day when J McD introduced the idea that there would be operators to interface with the computer. The programmers would only connect with the computer by proxy in future. The instructions for running the software and carrying out the testing had to be written down for use by others. It was the end of life as we knew it, but necessary in the evolution towards the use of more modern computer systems.
• I seem to recall that the first BAC KDF9 was to be installed at Bristol. J McD explained that success had already been achieved in the USA in connecting data links to computers over telephone lines. BAC was planning to work this way. I can remember thinking that it would never catch on in the UK because of the quality of telephone connections. (I also thought the Beatles were rubbish at the time and that they would not catch on either)
• One of the team, Dick Young, was a keen musician and talked of entering an international competition for computer music to be run in Monte Carlo in 1963 (?). I recall he programmed one of the Warton DEUCE's to play tunes and accompanied it on his trombone at Christmas 1962. Unfortunately the partying got a bit raucous and the CEO, Freddie (later Sir Frederick) Page stormed into the computer room and threw us all out.
• Possibly at the same or a similar party, with folks gathered around the computer after a drink or three, one member of the team was still trying to test out his program on this last afternoon before the Christmas break. He had also had a few drinks and did not spot that someone had fiddled with the card reader and removed the reading unit. As a result, the program and data were not getting into the computer. After many unsuccessful attempts, he finally realised that sabotage was going on. He picked up his pack of cards, which was about four inches thick, threw them up in the air and stormed out. At this point, the pranksters realised that the pack of cards had not been numbered! (Kept this in mind for years to come!)
• My last task before leaving was to work the night shift for two, or was it three, weeks with two others, completing a single matrix multiplication exercise for the Concorde fin stress analysis. This must have been a 'huge' task because one team did the day shift and then we carried on over-night. Although it was one large single task, I seem to remember that the work involved feeding in two sub-matrices which were multiplied together, and the results punched out as another sub-matrix. The DEUCE called for the each pair of sub-matrices at a time, giving their binary reference number (up to about 1000 in binary) on the display lights. One searched through boxes of cards for the right ones and fed them in. If we got the wrong ones, the computer blew its horn. The exercise would have been difficult enough if the set up had been correct. However the programmer had made a mistake and had written out a correction look-up list, i.e. the DEUCE gave you a large binary number, you translated this and used the look-up table to get the correct number, translated this back into binary and found the correct data pack (ultimately!). The glittering success of Concorde depended on this technology?
• An aside to the Concorde story, was the use of three operators on our night shift. Two worked on the task in hand, one to check the work of the other, - and the third slept inside the DEUCE on a mattress brought in for the night. Try that with a PC!
• Also linked to the Concorde work was the final anecdote. One night, a mercury delay line went down. Clearly, one of the other members of the team had been sharp enough to be able to diagnose this. The mercury was drained out, filtered through blotting paper, and reinstated. This achieved no success at all. A call went out to Kidsgrove for an engineer to start driving through the night with some fresh mercury (which was described as triple-distilled?). This was before the days of the M6 motorway as we now know it and so help was a long time away. It was decided in the meanwhile that we three would climb into the various test departments at Warton and forage for mercury. We ended up breaking thermometers, barometers and other instruments to recover a dubious sample of mercury. We filtered this through blotting paper, mainly to get rid of the glass, filled the faulty delay line -- and it worked! We were able to carry on with the task to the end of our shift. The Kidsgrove engineer arrived later that day to make the proper repair. (Not sure how popular J McD was with the other heads of department.)
I have recorded elsewhere that John McDonnell "was one of life's gentlemen, as well as being a first class mathematician". I do hope some of his former colleagues will find their way to the DEUCE web site and record a more appropriate tribute in due course. John was firm in his view that computer methods had to be totally sound. He often referred to a tome by Ferenc Lanczos (?) who had sought to put some rigour around the solubility of problems by computer. I recall that Lanczos had, for example, examined the conditioning of eigenvalue problems and suggested limits to the ratio of the largest off-diagonal term to the main diagonal, when solving digitally, i.e. one should seek to contain the size of computer models. When I met with John years later, and shortly before his untimely death, I said it continued to trouble me that issues we worried about on the DEUCE about conditioning, now seemed to be forgotten or were masked by the size and power of the modern computer. I could not see why 'Lanczos' should not apply equally then as it had done in DEUCE days. He replied, "it continues to trouble me too" patting the copy of Lanczos which he still kept on his desk.
© Peter Dukes - 23 June 2004