Actuarial Programming Methods
Total Page:16
File Type:pdf, Size:1020Kb
ACTUARIAL PROGRAMMING METHODS by E. S. ROBERTSON, F.F.A. and A. D. WILKIE, M.A., F.F.A., F.I.A. [Submitted to the Faculty on 31st March 1969. A synopsis of the paper will be found on page 180.] 1. INTRODUCTION 1.1. For some years now actuaries have been using computers for data-processing work. This mainly involved problems of the mani- pulation of files of policies, the selection of the right action to take for a particular policy, and the printing of appropriate notices or summaries. Only incidentally did any actuarial calculation enter into the programs, and what did—valuation of policies or groups, calculations for surplus, calculations of valuation factors or recosting rates—was tackled either by conventional methods, or by the first convenient new method that came to hand. Also, however, com- puters began to be used for specifically actuarial problems—the calculation of tables of commutation columns and policy values, tables of premium rates, specific rates according to new methods. Again, either a conventional method was used, or whichever new method the actuary or programmer could conveniently devise. Each actuary or programmer had to tackle each problem afresh, since as yet no set of standard methods, especially suited for computer work, had been published. 1.2. Early computers required their programs to be written in a machine language, which was specific to the particular design of computer used, was not readily intelligible, and required a large number of individual simple instructions. Refinements of machine languages produced assembler languages directly related to machine language, though with mnemonic order codes and named locations; the current examples of these are ICL 1900 PLAN, and IBM/360 Assembler language. If facilities are available for macro-instructions (as these two languages have) they can be made considerably more powerful. We shall mention later (9.3.6) how we see one possible line K 122 Actuarial Programming Methods of development through the use of macros. Nevertheless, these assembler languages remain specific to one design of computer, still require a large number of simple instructions, are largely incompre- hensible to someone who is not a trained programmer, and are not readily understood even by him. 1.3. The next development was the construction of “higher-level” languages. These permitted the programmer to use algebraic expressions to indicate how the value of a variable was to be cal- culated, and also included certain elementary English language instructions with words like “if”, “go to”, etc. A program written in one of these higher-level languages requires to be interpreted (“compiled” or “translated”) by another program (a “compiler” or “language translator”) and this program constructs a program suitable to be run on the particular computer used. But compilers exist so that all languages can be run on a variety of different machines, with less or more modification. However the essential part of a program in one of these languages remains constant, what- ever the computer used. The higher-level language therefore is not tied to one design of computer, is reasonably intelligible to someone who has taken a small amount of trouble to learn the language, and is in a much more concise form than an assembler-type language. 1.4. The various higher-level languages that are widely used have specific advantages for certain types of problem. COBOL is suitable for the manipulation of files of data, for business processing, character- handling, and printing. It is poor at pure mathematical work; it is also excessively wordy in its style. FORTRAN is very widely used mathematically; it is easily learnt, and has the necessary features for manipulating mathematical data; but it has poor facilities for character-handling and many of its features are matters of arbitrary convention rather than logical necessity. Algol is also a mathe- matically-oriented language, and has very poor character-handling and file-processing facilities; but it is more general and more powerful than FORTRAN in the mathematical area, and is also a very elegant language for expressing the essentials of a calculation if the calculation is not actually to be run on a computer. Other higher- level languages include PL/I, a new language that contains many of the good points of COBOL and FORTRAN and some of Algol, but in so doing is very elaborate and possibly not so readily learnt as a less powerful language; CPL, an Algol-like mathematical language; and Autocode and its derivatives, Extended Mercury Autocode and Atlas Actuarial Programming Methods 123 Autocode, which are used by many people in Britain, but which are unfortunately not familiar to the authors. Virtuous as it is to support home products, we feel that an undue proliferation of languages will only hinder the development of computer techniques, and it is the international languages that will allow us the international com- munication essential to actuarial and all mathematical work. For this, FORTRAN and Algol, despite their small number of English words, seem currently best suited. 1.5. One of our objects in this paper is to introduce to the Faculty a higher-level language, and we have chosen Algol for our example because of its mathematical elegance and its wide acceptance. It is also the language chosen by the Institute for their new Intermediate Subject (1) examination in Numerical Analysis. 1.6. We have mentioned that Algol is useful for expressing solutions even if a computer is not to be used for the actual calculation. Those concerned with computers have discovered that a “program” in a higher-level language can specify what has to be done in a given calculation more precisely and more explicitly than an explanation in ordinary language. If the procedure involves repetition or alterna- tive actions in different circumstances, then the “program” itself is the best way to define the operation or procedure. The “program” is the solution—not just instructions to a computer on how to calcu- late the solution. Algol is now widely used in mathematical works for the definition of a procedure, even though the “program” may be converted by a programmer into another language for the benefit of the computer. 1.7. We have just referred to the “program” as the solution to a problem. The better word is perhaps “algorithm”, which implies a mathematical or logical procedure that is independent of the notation used to express it. Just as Dy, y' and are alternative notations for the result of the operation of differentiating y, so an algorithm or program-solution remains the same whatever the notation— FORTRAN, Algol or plain English—used to express it. An algorithm can often be expressed or illustrated by a flow-chart (see 2.11) or in certain circumstances by one or more “decision tables”, which are a technique more applicable to data-processing, and not further discussed here. We hope to demonstrate the use of an algorithm in what follows, by taking certain elementary features of actuarial work 124 Actuarial Programming Methods and quoting possible algorithms for their solution. We cannot claim that our solutions are in any way the best; nor do they attempt to be comprehensive. But we hope that they will pave the way towards the regular publication of actuarial algorithms in the Transactions, so that those actuaries who have solved explicit problems can make their solutions available to those that follow. In due course a sufficient corpus of work may have been accumulated for someone to select the recognized standard methods and produce a text-book of actuarial programming, or incorporate the relevant parts into a revision of the official text-books. 1.8. We have tried to keep the student in mind when giving examples of actuarial methods. We are not proposing any immediate revision of the recently revised examination syllabus. But we use occasional examples from past examination papers in order to show how certain questions could be rephrased to elicit a program solution from the student. We do not think that it is yet possible to integrate programming with the examination syllabus, but we hope these examples give some indications of how this might be done in the future. 1.9. It will become evident on studying our program examples that the conventional actuarial notation does not readily fit into computer notation. For instance has to be altered into something like a(i, m, n). This would be the case whatever programming language was used. Further, there is so much freedom in naming variables that some sort of new conventions could prove very useful. Pro- posals have already been made on a revision of the actuarial notation, and we shall also discuss this point. 1.10. To those who have read this far, and may be put off by the unfamiliar terms and symbols that follow, we can only say “It is not nearly as hard as it looks, no harder than elementary algebra; do not despair yet”. 2. ALGOL 2.1. Since Algol will be used in this paper to illustrate some of the methods of programming it is necessary to describe some of the features of Algol. No attempt is made to teach the reader how to write programs accurately in Algol. There are many other publica- tions (1, 2)* that will do that. Only enough is explained to enable the * The references are listed at the end of the Paper. Actuarial Programming Methods 125 actuarial reader to follow the program examples and to appreciate some of the features that are present in any higher-level language. 2.2. Numeric Variables and Constants Variables in Algol are comparable with algebraic variables; they are given names that may consist of several letters or of letters and digits, but beginning always with a letter.