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:
My time and the knowledge gained with the DEUCE was extremely important later when I was running teams involved in finite element analysis, data communications, microprocessor control systems, etc. The 'old man' was able to surprise a lot of the 'young guys' with his knowledge of systems and software and inject constructive ideas for problem solving. I learned a great deal from, and owe a lot to, John McDonnell and John Halliday from my time in Maths Services at Warton, and this set me up for reasonably successful career thereafter. I would have to confess and regret that this was not matched by the effort I put in at the time.
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
To return to the DEUCE homepage click the image below.