Actuarial Programming Methods

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 manipulation 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, computers 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 calculated, 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, whatever 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 mathematically-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 communication 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 alternative 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 calculate 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. Constants are ordinary numbers with decimal points, and may be expressed with a scaling factor of some power of ten. Thus 250000 may be written as 2·5105, meaning 2·5 × 105. The subscript 10 is a special Algol symbol and in other languages this might be written 2·5E5, with no spaces between.

2.3. Real and integer forms Numeric variables are of two types: real and integer. An integer is a positive or negative integer with a size limited by the particular computer. Some languages (but not Algol) handle “fixed-point” numbers, where the program assumes a fixed decimal point some- where in the integer, in much the same way as a pointer is used in a hand calculating machine. Thus a variable may have to be described as having a fixed point with say five decimal places after it; the value ·12345 would be expressed as the integer + 12345, and the value ·00004 would be expressed as the integer +4. A real number is a positive or negative rational number, and is usually expressed in “floating-point” form inside the computer. In this form the location used to store the number is partitioned into an argument and an exponent. The argument is normally arranged so that | argument | lies between ½ and 1 (or 1/10 and1) and is a fraction given to a fixed number of binary (or decimal) places. The exponent may lie between, say, – 128 and +127, and gives the power of 2 (or 10) by which the fraction must be multiplied to give the true value. Thus, if an internal decimal scale is used, 250000 is stored as + ·25106, and – ·000195 is stored as – ·19510 – 3. Most computers can perform arithmetic on “floating-point” numbers, either by built-in instructions, or by programmed software. The advantage of floating-point working is that the programmer does not need to concern himself about the scaling of his results. The disadvantage is that spurious precision may seem to be achieved, for example if differences are taken. Thus, if a table of Sx is stored to six significant figures, the second differences, Dx, will be correct only to about four significant figures although they will still appear to the computer to have six. 126 Actuarial Programming Methods

2.4. Assignment statements These give instructions to calculate a value for a numeric variable in terms of other numeric variables, using the operators +, –, ×, /, • for addition, subtraction, multiplication, division, and exponentiation. Brackets are used to group items just as in algebra; multiplication must always be expressed by ×; and all expressions lie on one line. Thus, if y is to be calculated as ax2 + bx + c, we write: y: = a × x • 2 + b × x + c or more neatly: y: = (a × x b) × x + c since this both avoids the exponentiation that is performed rather slowly by most computers, and uses only two multiplications. It is possible also to write: x: = x + 1 which means “add one to x”. Thus the “compute” sign: = must not be mistaken for an algebraic equality. Variables of mixed real and integer type can be included in expressions, and the results will be calculated according to appropriate rules, with the final result expressed as real or integer depending on the variable on the left of: = . A real result is rounded to the nearest integer if the answer is to be integer, and the division / always produces real results, so that the integral result of 11/4 is 3. There is another operator ¸ that only operates on integers and produces the truncated result of normal division, so that 11 ¸ 4 is 2 and (– 11) ¸ 4 is –2. A fault of the language is that remainders are lost so that one must calculate A – (A ¸ B) × B to get the remainder when the integer A is divided by the integer B.

2.5. Functions Certain functions are built into the Algol system, and though they vary according to the computer they include such functions as sin (x), cos (x), arctan (x), x being in radians exp (x) i.e. ex ln (x) i.e. loge x sqrt (x) i.e. abs (x) i.e. |x| sign (x) i.e. + 1 if x > 0, 0 if x = 0, –1 if x < 0 entier (x) i.e. the largest integer not greater than x so we can write y: = sin (theta) • 2+ cos (theta) • 2 Actuarial Programming Methods 127 and expect to get the answer 1·0 or thereabouts. A useful test of the accuracy of the compiler that interprets Algol is to see how correctly it calculates such known results.

2.6. Boolean variables Another type of variable in Algol is the Boolean variable, which can have one of the two values true or false. These are used in conditional statements “if . . . then”. Conditional expressions can be formed from Boolean variables or from logical relations, which are made up of variables and the operators < > = such as: x < 4 b × b – 4 × a × c 0 There are also logical operators that can combine conditional relations or Boolean variables: Ø not: if A is true Ø A is false; Ù and: A Ù B is true only if both A and B are true; Ú or: A Ú B is true only if either A or B or both are true; É implies: A É B is false only if A is true and B is false; º equivalent: A º B is true only if A and B are either both true or both false. So if we are finding the roots of a quadratic, given a, b and c we may use at some stage: if then realroots: = true; and use the Boolean variable realroots at a later stage. Conditional statements are considered further in 2.10 below.

2.7. Block statements Variables must be declared before they are used, and the declaration must show whether they are real, integer or Boolean. A declaration applies only within one block, which is a set of statements enclosed by begin and end. A block may contain subordinate blocks, and declarations made in a superior block are valid in a subordinate one, though not vice versa. So if we write: begin real a, b; … begin real x, y; … end; … end; 128 Actuarial Programming Methods the variables a and b can be recognized throughout, but x and y are valid only from their declaration up to the first end.

2.8. Input and output Input and output instructions are not specified in the Algol report and vary according to the computer installation. For the purpose of this paper we shall define that the statements a:=read; b;=read; c:=read; cause three numbers to be read from some unspecified input device and assigned to a, b and c in that order. Also that the statement print (a, b, c); causes the values of a, b and c to be put out on some unspecified device to some specific number of significant figures, and a statement such as writetext (‘answer = ’); causes the actual characters enclosed in quotation marks to be printed.

2.9. Comments A very useful facility for annotating programs is the ability to write comment followed by any commentary you like which terminates at the first semicolon. The comment is ignored by the compiler and has no effect on the program.

2.10. Conditional statements These are introduced by if. . . then. . . and may be followed by else . . . Following the if is a Boolean variable or a conditional expression, and following then and else are statements, i.e. further instructions. Thus if we wish to calculate whether any year is a leap year (in the Gregorian calendar) we can write; begin integer year; Boolean leapyear; year: = read; if year–(year ¸ 4) × 4 0 then leapyear: = false else if year– (year ¸ 100) × 100 0 then leapyear: = true Actuarial Programming Methods 129 else if year – (year ¸ 400) × 400 0 then leapyear: = false else leapyear: = true; print (year); if leapyear then writetext (‘is a leapyear’) else writetext (‘is not a leapyear’) end; Note bow each else is written below the corresponding then for convenience; this is not essential to Algol. Note also that the else statement continues up to the next semicolon, so that after the first statement leapyear: = false the program goes directly to print (year). A shorter program with the same effect would be: begin integer y ; y:=read; print (y); if then writetext (‘is a leapyear’) else writetext (‘is not a leapyear’) end;

2.11. Go to statement An essential feature of any programming language is the ability to change the sequence of statements being obeyed. We have seen how a conditional statement allows alternative courses to be followed, but without allowing us to go back in the sequence and repeat instructions. It is often convenient to express some computation in the form of a flowchart. For example, if we wish to calculate the sum of the first n integers we could write a flowchart (see following page). We could then write an Algol program: begin integer n, sum, x; n: = read; sum:=0; x:=1; loop: sum: = sum + x x:=x+1 if x n then go to loop; print (n, sum) end; The word “loop” in this case is a label, and any name can be assigned to the label, just as for variables.

2.12. For . . . do . . . statement It is frequently useful to repeat the same procedure several times for different values of a variable. We may, for instance, wish to calculate 130 Actuarial Programming Methods

and print (1 + i)n for a series of values of n starting at 1 and increasing by 1 until n = 100. We could then write: begin real r, i; integer n; i: = read; for n: = 1 step 1 until 100 do begin r: = (1 + i) • n; print (n, r) end end; We might want to repeat this for a series of values of i, starting at ·001 and increasing by ·001 to ·1 (i.e. from ·1 per cent to 10 per cent). Actuarial Programming Methods 131 It would also be neater to avoid the exponentiation which is done every time in the program above. So we could now have: begin real r, i; integer n; for i: = ·001 step ·001 until ·10001 do begin writetext (‘ i = ’); print (i); r: = 1; for n: = 1 step 1 until 100 do begin r: = r × (1 + i); print (n, r) end of n loop; end of i loop; end; Note how r is set = 1 at the beginning of each loop and is used to calculate the next value of r. See also how two for-loops are nested one inside the other, so that for each rate of interest 100 values of (1 + i)n are produced. Finally, note that the upper limit for i is taken as ·10001, since a real variable may not be accurately expressed in decimals, and the margin makes sure that the program stops after ·100 and not just before. A second form of for. . . do . . . statement includes a while condition e.g. for r: = r + 1 while a > tol do. . . This will step up the variable r by 1 each time, and come out of the loop when a tol.

2.13. Arrays In actuarial work, as in much mathematical work, it is common to use columns of values, rectangular tables, or arrays in three or more dimensions. The variables in the array could be referred to as aij or as where i, j, x and n are subscripts. In Algol an array can also be defined, and the items in it can be identified by subscripts thus:

a[i, j] or assurance [x, n] Before an array is used its type must be declared and the ranges of the subscripts must be given. Thus: real array A[1 : 100], assurance [20 : 80, 5: 70]; defines a column with 100 elements numbered from 1 to 100, and a rectangular table where the first subscript runs from 20 to 80 and the second from 5 to 70, a total of 4026 elements. In practice actuarial arrays are often 132 Actuarial Programming Methods triangular, but Algol makes no provision for this. But in matrix work rectangular arrays are normal, and Algol allows easy reference to the elements of a matrix,

2.14. Procedures Besides the built-in functions referred to in 2.5 it is possible to invent new functions, provided these are defined in the program. Function procedures have a name and then a series of parameters; their type must also be declared. We might wish to have a procedure to calculate for any given i and integral n, so we could write: real procedure anncert (i, n); real i; integer n; comment this is the procedure heading and it tells us what type of variables anncert, i and n are; begin real v; v: = 1/(1 + i); anncert: = (1 – v • n)/i end; Whenever we use anncert (i, n) or anncert (j, p) or anncert (·05, 10) the appropriate value of anncert will be used in its place. A different type of procedure is a general procedure. In this, a name and a list of parameters are also given, but the action of the procedure is to alter the values of some of the parameters, or possibly to do some other fixed action. To use the procedure the name and a parameter list are given. Thus a procedure might be available to skip the printer to the head of a new page. Its name is ‘newpage’ and by writing: newpage; in the program the appropriate action is taken. Another example, with parameters, would be to sum a column of figures from the bottom up, leaving the results at each stage in a second column, for instance calculating Nx from Dx. We could write: procedure sumup (dcom, ncom, first, last); real array dcom, ncom; integer first, last; begin real sum; integer x; sum: = 0; for x: = last step – 1 until first do begin sum: = sum + dcom [x]; ncom [x]: = sum end end; So if we write: sumup (c, m, 1, 100) where c and m are arrays with bounds 1 and 100 we get the result of the summing of the array c left Actuarial Programming Methods 133 in array m, and if we follow this by: sumup (m, r, 1, 100) we get the result of the same operation on m left in array r.

2.15. Conclusion It can be seen from this summary of the main features of Algol that it is an elegant, easily written, and easily understood programming language for mathematical work. On the other hand it is not designed for use in commercial data-processing. It is not possible to have a variable consisting of letters, so names, addresses and alphabetic codes cannot be handled. We cannot put: if month:=january or if name>smith, with any hope of being understood. COBOL (or PL/I) is required for this sort of work. But our purpose in this paper is to illustrate some of the actuarial and mathematical uses of programming, and for this Algol is very well suited.

3. NUMERICAL ANALYSIS 3.1. Since computers, by their very name, deal mainly with the calculation of numerical answers it is natural that attention should be paid to numerical analysis and computational methods. A great deal of computer literature deals with the algorithms, or procedures, that enable one to perform some calculation or operation accurately and conveniently. Algorithms do not all deal with purely numerical work. They may be concerned with sorting information into alpha- betical order, analysing sentences grammatically, or using a series of conditional statements to attach the right name and address to a premium notice; but the main interest of this paper is in numerical algorithms.

3.2. Functions In section 2.5 we referred to the built-in functions of Algol, such as sin (x), exp (x), sqrt (x), etc. The user of Algol may not have to worry about how the computer performs the calculations for these functions, but he may have to concern himself with the calculation of other functions not built-in; or he may be using a language (such as COBOL) with no useful built-in functions; or he may be the writer of an Algol compiler in the first place. He therefore may have occasion to write a function subroutine himself. Fortunately many suitable methods have already been published (3, 4), but even if he can borrow a convenient method, he has to consider the accuracy, range of argument, and special conditions he may meet, such as what he does if 134 Actuarial Programming Methods a negative x is used as the argument of a square root subroutine. If we ignore these problems for the moment, we can readily see that the usual expansions in powers of x give us one way to calculate, for instance exp (x)

real procedure exp (x); real x; begin real u; integer r; u:=1; r:=1; exp:=0; loop: exp: = exp + u; u: = (u × x)/r; r: = r + 1; if u > exp × 0·0000001 then go to loop; end; This calculates exp (x) correct to six significant figures, which may be satisfactory only for selected purposes. The if statement could be replaced by: if u > ·0000001 then go to loop; thus giving exp (x) correct to six decimal places, which may suit better a certain range of values of x. For many functions a polynomial function y = P(x) or a rational function y = P(x)/Q(x) gives an answer to a satisfactory degree of accuracy over a suitable range of values of x. Thus an alternative method for calculating exp (x) is to use the formula:

which for 0 x 0·1 gives an accuracy of more than 10 significant figures (see reference 5, formula EXPEC 1800). Other methods require the use of continued fractions, e.g.

for

or infinite products, e.g.

or other mathematical devices that it is beyond the ability of the authors to explain. A very full description of many such methods, with further references, is found in Computer Approximations (5). Actuarial Programming Methods 135 3.3. Roots of equations It is not infrequently required to find the root or roots of an algebraic equation f(x) = 0. An iterative technique is the normal method, and the most popular technique is probably the Newton-Raphson method:

To use this we need to be able to calculate f(x) and f’(x) by some procedure, to select an appropriate value for x0 and to determine a degree of accuracy that will allow us to stop the iteration. Specific uses of the Newton-Raphson method are in the calculation of the square root and cube root of a number, by solving the equations x2 – a = 0, or x3 – a = 0. In the first case we obtain:

to give and perhaps use x0 = ½a as a first approximation, and in the second we have:

to give and perhaps use x0 = 1/3aas a first approximation. Whether the special cases are important, such as a being negative when we are seeking or f'(x) being zero in the general case, depends on the particular problem. It may well be that they can be ignored unless we are writing a general subroutine to be used by other programmers which must therefore take into account all possible cases, however nonsensical they may appear.

3.4. Finite Differences 3.4.1. The fundamental application of finite difference methods is interpolation, either of single values or of a series of values, given a table of f(x) for either equal or unequal intervals of x. The first step towards this may be the calculation of first and subsequent differences in a difference table. A number of procedures might be used, of increasing complexity, to provide differences. In each case we enter the procedure with an array containing n values, referred to as f[1] to f[n], but possibly being values of f(x) for x = 0 to x = n–1.

3.4.2. The first, elementary, procedure is to calculate an array, d, of first differences, with n – 1 values, giving Df[1] to Df[n – 1]: 136 Actuarial Programming Methods procedure first difference (n, f, d); integer n; real array d, f; begin integer i; for i: = 1 step 1 until (n – 1)do d[i]: = f [i + 1] – f[i] end;

3.4.3. Of more use, perhaps, is to calculate all available differences up to D n–1f[1], and to place them in a square array d[i, j] of size (n – 1) by (n – 1), so that d[i, j] = D if[j]: procedure difference square (n, f, d); integer n; real array d, f; begin integer i, j; for j: = 1 step 1 until (n – 1) do d[1,j]:=f[j+1]–f[j]; for i: = 2 step 1 until (n – 1) do begin for j:= 1 step 1 until (n – i) do d[i, j]: = d[i – 1, j + 1] – d[i – 1, j] end end;

3.4.4. However it is clear that the square array of d[i, j] has nearly half its values unfilled, so in order to conserve space in the computer it may be convenient to rearrange the differences in a single array d[k] of length ½n (n – 1), representing in effect the triangular pattern of differences. This array contains in sequence: and any value D if[j] can be found by d[k] where k = ½(i – 1) × (2n – i) + j. The table of d[k] is given by the procedure: procedure difference triangle (n, f, d); integer n; real array d, f; begin integer i, j, k, l; for k: = 1 step 1 until (n–1) do d[k]:=f[k+1]–f[k]; k:=n; l:=0; for i:=2 step 1 until (n–1) do begin l:=l+1; for j:= 1 step 1 until (n–i) do Actuarial Programming Methods 137 begin d[k]: = d[l + 1] – d[l]; l:=l+1; k:=k+1 end end end; It may be worth pointing out that the difficulty in constructing or understanding this algorithm is in getting the subscripts k and l stepping up correctly through the table; the arithmetic is naturally trivial, but the point of constructing the algorithm for general use is to save oneself or others the trouble of working out the correct pattern of subscripts.

3.4.5. Let us now assume that we have calculated array d by means of the last procedure. We now wish to enter the table with argument x and interpolate to give y = f(x). Note that we assume that f[1] = f(0). If we use Newton’s advancing difference formula we get: procedure Newton interpolation (n, f, d, x, y); integer n; real x, y; real array d, f; begin integer i, k; real a; a:=x; y:=f[1]; k:=1; for i: = 1 step 1 until (n – 1) do begin y:=y+a × d[k]; k:=k+n–i; a:=a×(x–i)/(i+1) end end; When we have unravelled this we see that we are starting with y = f(0), and adding to it a further (n – 1) terms as we go round the do-loop, the terms being successively etc. up to The multiplier a is calculated by a recurrence relation and the subscript k steps up through the triangular-straight-line array by successively n–1, n–2, n–3 etc.

3.4.6. This procedure is suitable for finding an individual value when the difference table is already constructed; but if the array d is not yet L 138 Actuarial Programming Methods available and only one value is required it may well be more convenient to use a Lagrange formula, and calculate y = f(x) directly in terms of the elements of array f. The Lagrange formula is also useful when the intervals are unequal, in which case we need two arrays to define the table, one with the values of x, the other with the values off(x). An algorithm for Lagrange interpolation for unequal intervals is given in Bull, p. 96 (3). The choice of which method to use in the computer may depend on the particular computer, compiler and application being considered. Our purpose here is primarily to point out possible methods; experience will show which are the most economical in mechanical and personal effort.

3.4.7. Another likely application of interpolation is in the calculation of values at regular intervals of the argument given values of the function at equal but larger intervals of the argument, i.e. given f(0) to f(n – 1) for x = 0, 1, 2 . . . to n – 1, we require f(0), f(h), f(2h), f(3h) … f(n –1) where h = 1/p and p is normally an integer. The common actuarial case is in interpolating for single ages having calculated values at quinquennial ages. (It may be argued, of course, that with a computer we would naturally calculate each single age separately from first principles; but cases may well arise where only quinquennial values of l(x) say are available in an abridged life table, which we now wish to complete). A suitable method is possibly a cubic interpolation between adjacent values of f(x), using f(x – 1), f(x), f(x + 1), f(x + 2) to derive f(x + h), f(x + 2h) … f(x + 1 – h). In the two end intervals we cannot use four points in the same way, so we could perhaps use f(0) to f(3) to derive all values from f(0) to f(2), and similarly f(n – 4) to f(n – 1) to calculate all values from f(n – 3) to f(n – 1). A Lagrange formula can conveniently be used, with the coefficients’ of f(x – 1) etc. being calculated by the procedure in the first place, and then applied. We can define the procedure as: procedure interp (n, f, p, g) where the array f contains n values of the function, i.e. f[1] to f[n], and the procedure inserts in array g a total of 1 + (n – 1) × p values of the function, g[1] to g[1 + (n – 1) × p] for values of the argument at intervals of 1/p; g[1] = f[1] and g[1 + (n – 1) × p] = f[n]. We leave it to the enthusiastic reader to complete the algorithm.

3.5. Differentiation and Integration 3.5.1. Finite difference methods include also those for finding differentials of a tabulated function in terms of differences, or for finding the Actuarial Programming Methods 139 definite integral of a function over a given range by suitable approximate methods. Indeed this may be the only practical way in which to obtain the value of the integral for various mathematical functions which cannot be integrated by calculus. Different methods are used for each of these cases. The problem of finding the differentials at one point on f(x) or at a series of points is not essentially different from interpolation, with a different function of the values off(z) or the differences being used.

3.5.2. A function may be tabulated at equal or at unequal intervals. For integration at equal intervals either Simpson’s rule repeated or the three-eighths rule repeated or a combination of both will give reasonable results. A general procedure could provide an array g which gave values of A simpler method,

which can also be used for unequal intervals, is the trapezoidal rule. Yet other methods are available, both for equal and unequal intervals, if the first or second derivatives of the function are also available. A series of algorithms for these are available in the IBM System/360 Scientific Subroutine Package (6), which gives references to the further mathematical background. For normal actuarial purposes Simpson’s rule repeated is probably quite satisfactory.

3.5.3. Of greater mathematical importance is possibly the case where the function can be calculated for any value of the argument, but no analytical method is available to find the integral. Amongst other functions the familiar normal distribution probability integral is one:

For convenience of calculation it is preferable to find the integral from 0 to x for positive values of x, and a straightforward method is to divide the interval from 0 to x into two parts, giving t = 0, x/2, x, with a first approximation of:

A second approximation is given by dividing the interval into four and using Simpson’s rule repeated twice, i.e. 140 Actuarial Programming Methods

The process can be repeated in the usual way until two successive values are sufficiently close. The procedure could in general be specified as procedure Simpson (a, b, f, y, tol) where a and b are the lower and upper limits of integration, f is the name of a function subroutine, and y is the result i.e.

to a specified tolerance tol. Since there are two auxiliary functions that help in the calculations it may be helpful to show a flowchart for the procedure (Figure 1) and the procedure itself. procedure Simpson (a, b, f, y, tol); real a, b, y, tol: real procedure f; begin integer n, i; real g, h, k, oldy; Boolean firsttime; n: = 1; firsttime:= true; h:= f(a) + f(b); loop: n: = 2 × n; k: = (b–a)/n; g:=0; oldy:=y; for i: = 1 step 2 until (n – 1) do g:=g+f(a+i × k); h:=h+2×g; y:=(h+2×g)×k/3; if firsttime then begin firsttime: = false; go to loop end else if abs (oldy – y) > tol then go to loop end;

3.5.4. We can perhaps use this example to show how to calculate the probability integral for values of x from 0 to 5·0 at intervals of 0·1, giving the ordinates and the integrals

both to five decimal places.

begin real x, pi, sqtpi, p, bigf, y, tol; real procedure f(t); real t ; f: = exp (– t × t/2); tol:=0·000001; pi:=3·141592; sqtpi:=1/(sprt (2 × pi)); writetext (x P(x) F(x)); Actuarial Programming Methods 141

Figure 1 142 Actuarial Programming Methods for x: = 0·0 step 0·1 until 5·0 do begin p:=sqtpi × f(x); Simpson (0, x, f, y, tol); bigf: = sptpi × y + 0·5; print (x, p, bigf) end end; This has in fact been run on an ICL 1904 and the complete program and results, together with the sort of miscellaneous information that a computer produces, are shown in Figure 2.

3.5.5. It may be of interest to quote in full question 19 from the Third Paper Part I of the Faculty examinations for September 1968: “Derive the approximate integration formula:

Putting

and

show that

You know how to calculate ux for any value of x, but you do not know any expression for Show how you would use the

above results to evaluate , for particular values of a and b,

to a given number of decimal places.” It is clear that the last sentence could have been rephrased:

‘Write a flowchart to evaluate for particular values of a and b,

to a given number of decimal places”, or even “Write an Algol procedure” to do the same.

3.5.6. Under the general heading of calculus procedures may be included the problems of the numerical solution of differential equations given certain starting values of y0, y'0, y"0 etc. as required. These are of considerable interest in other subjects, but since they have not received much attention in the actuarial field they will not be discussed further here. Actuarial Programming Methods 143 3.6. Solution of simultaneous equations The traditional problem of solving n simultaneous linear equations in order to find the values of n unknowns is closely related to the problems of matrix arithmetic. A disadvantage of matrix work in the past has been the excessive arithmetical labour involved; obviously this is entirely suitable work for a computer. A variety of methods of solving simultaneous equations—or its equivalent procedure, inverting a matrix—are now available. They start with the elementary school method, elaborated with the name of Gaussian elimination or pivotal condensation. This method involves the selection of a pivot at each stage, the pivot being the largest element in modulus in each column. Rows are interchanged, multiplied and subtracted, until a series of equations that began:

is transformed into:

whence by repeated substitution we find the values successively of xn, xn–1 … to x1. Other methods are elaborations of this direct technique. A second line of approach is by repeated approximation, and a further variety of techniques is based on this. The relative advantages of the methods may depend on the pattern of non-zero terms in the matrix A. We do not intend to quote any method in full, since they are all com- paratively lengthy and all well documented in one or more of our references (3, 4). A variety of FORTRAN subroutines is also published by IBM (6). The real importance of these in actuarial work is first in multivariate analysis in statistics, where a least-squares solution resolves into a set of n linear equations, and secondly in curve-fitting where again a least-squares solution for a formula with n parameters will resolve into the same problem of simultaneous 144 Actuarial Programming Methods equations, which can be solved by standard methods, at least if they are linear. The latter point is discussed again later in Section 7.

4. STATISTICS 4.1. In common with most other subjects of applied mathematics the practical purpose of statistics is to produce numerical results from live data. The collection of the data is mainly a practical and “data-processing” problem, and the interpretation of the results remains a matter of statistical judgement. However the computer can clearly assist the statistician by performing the usual tedious arithmetical work for him, thus allowing him to attempt far more ambitious schemes of calculation than previously. Again, a series of standard subroutines is what he needs, and computer manufacturers and statisticians have produced a number of these. Indeed recently the Royal Statistical Society has begun to publish statistical algorithms in its series Applied Statistics (7).

4.2. The sort of subroutines that the statistician might need for dealing with a series of multivariate observations include: — a scan of the data to provide means, standard deviations, minimum and maximum observations; — a test to see whether a normal distribution (or some other distribution) fits the data for one variable at a time; — tabulation of the data for one variable or any pair of variables; — correlation coefficients between each pair of variables; — multiple linear regression for any selection of variables; — facilities to introduce functions of other variables, so as to include, say x2i, as another variable, and so extend the linear regression model; — comparison of the multiple regression coefficients with their esti- mated standard errors, so as to eliminate the least significant variables from the regression and repeat the procedure with the remaining variables; — calculation and tabulation of the residual differences for one regression; — discriminant analysis, to distinguish two or more groups in the population; — principal components analysis, to find the principal axes of the multivariate distribution; — etc. Actuarial Programming Methods 145

In other fields the statistician might use; — autocorrelation of time series; — rank correlation calculations; — c 2 test on contingency tables with several factors; — analysis of variance with several factors; — calculation of values for missing data in factorial experiments; — calculation of standard tables e.g. for the normal distribution (as in 3.5.4 above), c 2 and F distributions; — etc.

4.3. The actuary investigating mortality statistics may perhaps find that what he needs includes: — procedures for appropriate exposed to risk formulae, given tables of beginners, enders, deaths, withdrawals, etc. — calculation of independent death rates or withdrawal rates for one or more causes of decrement; — fitting of one curve to the observed death rates by a least-squares method; — comparison of the fitted curve to observed rates by a c 2test; — a generalized fitting of a series of appropriate curves with a comparison after each test; such curves could be polynomials of ever-increasing degree, Perksian curves of increasing complexity or any others that the actuary and programmer can devise between them; — alternatively, comparison of observed data with standard mortality tables; — fitting of standard mortality tables to observed data, adjusting by means of say an added constant, a multiplied constant, and an age shift; — the elaboration of all the above methods to cover the case of a select table, or generation tables; — projection of generation tables in some appropriate way.

The authors do not pretend to have devised solutions to all or indeed any of these procedures; but we hope that it can be recognized at least that these are indeed standard procedures, which could be readily programmed, and for which the algorithms could be accumulated and published for general use. Our main plea is that actuaries should be prepared, and encouraged, to study both the mathematical background to some of these problems, and the existing statistical algorithms. 146 Actuarial Programming Methods

5. COMPOUND INTEREST 5.1. The fundamental relations of compound interest to which the student is first introduced are:

For many purposes it is convenient to be able to calculate d or d given i, or i(m) and d(m) given i and m. In Algol d is easily expressed as ln(1 + i), and d as i/(1 + i). Likewise and If the exponentiation operator wore not available we could calculate both i(m) and d(m) using the expansions:

procedure interest (i, m, im, dm, tol); real i, m, im, dm, tol; begin real a, b; integer r; im:=dm:=0; a:=b:=i; r:=1; for r:=r+ 1 while abs(a) > tol Ú abs(b)>tol do begin im:=im+a; dm:=dm+b; a: = –a × i × (r × m – m – 1)/(r × m); b:=–b×i×(r×m–m+1)/(r×m) end end; We have made no tests to ensure that the initial values of i and m are sensible ones—this further elaboration might be desirable in a practical subroutine. But although m is normally an integer such as 2, 4, 12 or 52, the formula is valid for any value of m, and we can note that since d(m) = m{1 – (1 + i)–1/m) d(–m) = (– m){1 – (1 + i)1/m} = i(m) Actuarial Programming Methods 147 so by defining i(m) as d(–m) we can combine the calculation into one procedure:

real procedure dm (i, m, tol); real i, m, tol; begin real b; integer r; dm:=0; b:=i; r:=1; for r:= r+ 1 while abs(b)>tol do begin dm: = dm+ b; b:=–b×i×(r×m–m+1)/(r×m) end end; Neater, of course, is the direct calculation using exponentiation:

real procedure dm2 (i, m); real i, m;

5.2. It can also be noted that and bearing in mind that d(–m) = i(m), a general procedure can be written to calculate or :

real procedure snc (i, n, m); real i; integer n, m; begin end;

This procedure will calculate if both n and m are positive; if the parameter m is set with a minus sign, will be calculated. If n is set with a minus sign, m being positive, will result. If or is required, m should strictly be set as ± ¥. This however would produce an indeterminate quantity which the computer could not value (even if it were possible to set such a value in store). For all practical purposes the setting of m to a large number, say 1000, would be sufficient, assuming that the exponeniation function used by the program will provide sufficient accuracy. The above procedure will also calculate i/d(m) and i/i(m) by putting n = 1 and setting m positive and negative respectively, since

Similarly i/ d would be produced by setting n = ±1 and m = 1000, say. Alternative conventions could be adopted regarding the signs of 148 Actuarial Programming Methods n and m and the above procedure altered accordingly; we have arranged the signs so that the value of snc is reduced on a change of sign from positive to negative in either n or m. If it were desired to produce a table of values of and for all terms up to n years and for m = 1, 2, 4, 12, the following procedure would do it: procedure snc table (i, n, p, m, sc); real i; integer n, p; real array m, sc; comment i is a rate of interest, m is an array with p entries so that e.g. m[1] = 1, m[2] = 2, m[3] = 4, m[4] = 12, etc. The output is an array sc of size 4 × n × p with entries for a(n) followed by ä(n) s(n) and i(n) in that order; begin integer r, s, t; for t:= 1 step 1 until p do for s: = 1 step 1 until n a0 sc[r, s, t]:=snc (i, if r = 1 Ú r = 2 then – s else s, if r = 1 Ú r = 3 then – m[t] else m[t]); end;

5.3. The next problem we shall consider is the repayment schedule for a loan repaid by means of an annuity certain with level instalments of capital and interest. The rate of interest is i per annum, the amount of the loan is S, the period of the loan is n years, the frequency of repayment is m (in arrear but with m positive), and the rate of tax on the interest portion is t. We shall print a schedule giving in successive columns the year (y), the number of the payment in the year (p), the principal outstanding before the payment (s), the gross interest (grossi), the net interest (neti), the amount of tax (tax), the amount of principal repaid (repay), the amount of principal outstanding after the payment (pout), and the total payment net of tax (netpay).

begin integer n, m, r, y, p; real i, S, t, imfac, k, grossi, tax, neti, repay, pout, netpay; i: = read; S: = read; n: = read; m: = read; t: = read; k:=S/(m × snc (i, –n, –m)); imfac:=(1+i) • (1/m)–1; print (i, S, n, m, t, k); for r:= 1 step 1 until (m × n) do begin y: = (r – 1) ¸ m; p: = r – m × y; grossi: = S × imfac; tax:=grossi × t; Actuarial Programming Methods 149 neti: = grossi – tax; repay:= k–grossi; pout: = S – repay; netpay: = repay+ neti; print (y, p, S, grossi, tax, neti, repay, pout, netpay); S: = pout end end;

By expressing the variables mainly in real form we have evaded the problem of expressing the results in integral units of currency, or of converting to £ : s : d, and of making sure that the total capital repayment adds up correctly to the amount of the original loan, but these, we feel, are primarily problems of data processing or of input and output. The format of the printed values must, of course, be described in some manner in the print statement, and this will depend on the particular compiler in use.

5.4. Many problems of compound interest (or “discounted cash flow”) require the calculation of the effective rate of interest in a transaction, or the redemption yield. Assuming that the payments are made at regular intervals of time (say 1 year), then the equation of value can always be expressed in the form:

where often all the Ai are positive except A,. Provided this is the case the polynomial in v has only one positive root, and for normal compound interest problems a first approximation of v0 = 1 will be a suitable starting point. The Newton-Raphson method (see 3.3.) is an obvious possibility. For the special case where all the Ai except A,, are equal, we have the problem of finding the rate of interest of an annuity certain:

In this case the Newton-Raphson formula:

becomes: 150 Actuarial Programming Methods To simplify this further may be awkward if v0 = 1, for then the corresponding becomes But if a general Newton-

Raphson routine is available it is easy enough simply to supply the array of coefficients An . . . . A0 for every case. In the situation where there is already a close approximation to the root, as when a stockbroker is calculating the redemption yield of a stock at today’s price, knowing yesterday’s redemption yield, the Newton-Raphson method can be made faster by using this yield as the first approximation. And provided vr does not become 1 we can simplify the expression of vr+1 further:

where the right hand side is calculated at the rate corresponding to vr. (This, incidentally, is a rapid method of finding i by hand calculation; having found a value of ir, ir+1 can be obtained by using the tabulated values nearest to ir.) The usual formula for calculating the price of a redeemable security is where C is the amount to be repaid after n years, and gC is the dividend per annum payable p times a year. If we let where A' = A/C, the yield will be found from f(i) = 0.

Now

Since Actuarial Programming Methods 151

Using the Newton-Raphson method,

The following procedure will calculate the redemption yield for a redeemable security. It is assumed that n will always be set positive, but that p will follow the convention mentioned in 5.2, i.e. it is negative if in arrear. As before, tol is the tolerance to which the yield is to be calculated. It will be noted that the first value of i is taken as g. real procedure redemption yield (g, n, p, c, a, tol); real g, c, a, tol; integer n, p; begin real i, adash, newi, v, anc, imratio, dmratio, factor; adash: = a/c; newi: = g; loop: i:=newi; v:=1/(1+i); anc : = snc(i, – n, p); imratio: = snc(i, 1, p); dmratio: = snc(i, 1, –p); factor: = (g × anc – (adash – v • n))/(g × anc × v × dmratio + (i – g × imratio) × n × v • (n + 1)); newi: = i × (1 + factor); if abs (newi – i) > tol then go to loop; redemption yield: = newi end; The authors do not know what method of calculating redemption yields is actually used by those stockbrokers who publish them daily, and are well aware that more concise methods suited to the particular case could have been devised. The root of the equation f(v) = 0 may be found to be either greater or less than 1, corresponding to either a positive or a negative rate of interest. This is a natural feature of any method. Further, if any of the Ai other than A,, are negative, there may be more than one real root; if all the Ai are positive and n is even, there may be no real root. A suitably general procedure for polynomial roots will treat all cases appropriately and return either all the roots, real or 152 Actuarial Programming Methods complex, or all the real roots, with an indication of how many there are. It is interesting to note how easy it may be to produce large numbers of completely unwanted results!

5.5. The value of a security which is redeemed by a cumulative sinking fund can be calculated quite easily using an Algol procedure. We here consider the case of a loan of c repayable by an annual service of (g + z)c, where drawings are made yearly but interest is paid p times a year, the valuation rate of interest being i. First of all the term of the sinking fund and the final payment of capital are found, and the capital is then valued directly. From the Makeham formula is found the value of the interest payments which is then adjusted to allow for the frequency of the interest payments. real procedure csf (g, z, c, i, p); real g, z, c, i; integer p; begin real finpay, idash, valcap, v; integer n; v:=1/(1+i); n:=entier (ln(l+g/z)/ln(1+g)); finpay:=1–z×snc(g,n, – 1); idash:=(1+i)/(1+g)–1; valcap: = v × z × snc(idash, –n, –1) + finpay × v • (n+1); csf: = (valcap+g/i × snc(i, 1, p) × (1 – valcap)) × c end; The above procedure makes no allowance for either income tax or capital gains tax, and it could be adjusted to deal with this if the appropriate rates were fed in as parameters. With a slight alteration it could however be used to produce values which could be adjusted to allow for tax. Consider question 2 from the First Paper Part II of the Faculty examinations for April 1968. The question reads: “A loan bears interest at 6% per annum payable yearly and will be redeemed at 120% by a cumulative sinking fund of 2% operating by annual drawings. At the date of issue the total loan is to be taken up by an institution which assumes that it will be subject to income tax at 8s. in the £ and to a capital gains tax of 30% payable on the difference between the redemption price and purchase price of bonds drawn. Calculate the price paid per £100 nominal of the loan if the institution wishes to earn 4½% net effective per annum after allowing for income tax and capital gains tax.” If A is the value before any allowance is made for tax, this value can be simply adjusted to allow for income tax if the value of the capital Actuarial Programming Methods 153 repayments K is known. A' = A–t(A–K), where t is the rate of income tax. If A" is the actual price to be paid, the amount of capital gain at each redemption is (C–A”) and the tax on it is cgt × (C–A”), where cgt is the rate of capital gains tax. The value of the capital gains tax has to be found at the valuation rate of interest and this will be

Whence

All we need do, therefore, is alter the procedure csf so that K is given as a result as well as A, at the same time changing it from a function procedure to a general one. The program to calculate the required price would then be: begin real a, k, result; csf (0·06, 0·02, 1·2, 0·045, –1, a, k); result: = 100 × (a × 0·6 + k × 1·2 × 0·1)/(1 – 0·3 × k) end;

Note that if the procedure csf uses valcap to set K, this will have to be multiplied by C to produce the correct value of the capital repayments K, as used in the formula above.

6. LIFE CONTINGENCIES 6.1. The standard commutation functions were derived to enable life assurance and life annuity values to be readily calculated at a given rate of interest. When a computer is available for the calculation of these values, the use of these standard functions is not necessarily the best way to solve the problem.

6.2. If a standard mortality table is to be used and the rate of interest is one for which published commutation values exist, the calculation of life assurance and life annuity values can be made directly from the commutation values. In order to keep to a minimum the space required in the computer to store these commutation values, only those for Nx need be stored assuming that increasing assurance or M 154 Actuarial Programming Methods annuity values are not required, for the other standard commutation functions can be easily derived as follows: Cx = vNx–(1+v)Nx+1+Nx+2; Dx = Nx–Nx+1; Mx = vNx–Nx+1. If increasing assurance or annuity values were required, a table of the values of Sx could be stored and all the other functions derived from it, although if the program were to be used principally to calculate the normal assurance or annuity values, it would be better to store the Nx table and use this so as to keep the formulae as simple as possible and to arrange for the Rx and Sx values to be calculated whenever necessary by summing the appropriate Nx values.

6.3. The rate of interest may not be one for which commutation values are published, or the mortality table may not be a standard one. In this case it can be arranged that before the calculation of the life assurance or life annuity values is carried out the computer produces a table of Nx (or Sx) from which the required values will ultimately be calculated.

6.4. In present times of high interest rates there is a tendency for offices to use rates of interest which either vary with the term of the contract or from year to year. In such cases it is not practicable to store all the commutation values that might be required, and the best method is to build up the required assurance or annuity values from the basic mortality rates. The following relationships would cover the more common values:

where v might vary either with n or with r.

6.5. Values of qx would be the basic function to be read in, in preference to lx or px, for the following reasons: (i) qx × 10n can be punched in the form of an integer (where n is the number of decimal places for which qx is given), so there is less punching required than if either of the other two functions had been used; Actuarial Programming Methods 155 (ii) if special mortality is to be used, it is more likely to be expressed in the form of a new table of qx, or as an adjustment to the existing table of qx.

The following procedure statement would read in the values of qx, carry out a check on the values and at the same time calculate px which is slightly more easy to use than qx in the recurrence relationships mentioned in 6.4.

procedure read lq (x, lp, b); real array lp; integer x, b; comment b is the maximum number of qs that can be read in and x is the age for the first q; begin integer i, j, r, sum; for i: = 1 step 1 until 3 do begin sum:=0; j:=x–1; r:=0; for j: = j + 1 while r ¹ 100000 do begin r:=read; sum:=sum+r; lp [i, j]: = 1 – r/100000 end sum: = sum + read; if sum ¹ 0 then error; comment error is a separate procedure to deal with errors; for j:=j step 1 until x+b–1 do lp [i, j]:=0 end end;

In the above procedure it has been assumed that the mortality table has a select period of two years and that the q’s are given to five decimal places. The data tape or cards would have the select q’s × 105, the (select+ 1) q’s × 105 and then the ultimate q’s × 105. The last q shown in each group would be 105 so that the end of the group can be recognized, and this would be followed immediately by a negative checksum (i.e. the complement of the sum of the q’s in the group). The object of this checksum is to enable the computer to put on a check that all the q’s in the group have been read correctly. Once the q’s have been read in, the p’s calculated and the checksum verified, the procedure fills in any empty elements in the array with zeros; this enables the end of the table to be recognized and also avoids any seemingly correct results being produced if the end of the table is inadvertently passed. The way in which the select and ultimate values are stored is not the same as the way in which they appear in the published tables e.g. lp [2, x] contains p[x–1]+1 and not p[x]+1, since it is easier to handle the stored values if x always represents the attained age. 156 Actuarial Programming Methods 6.6. It will be noted that a two dimensional array has been used in the procedure in 6.5 to store the calculated values of px. If the mortality were annuitants mortality, the array would be filled since all values might at some time or other be required if select immediate annuities were to be calculated. If, however, the values of px were for assurance mortality, the select and (select+ 1) values would be unlikely to be required for the whole range of ages up to w so that there would be some space wasted in store. A technique similar to that employed in 3.4.4 could be adopted to produce a one dimensional array. If storage space were vital, this system could be used, but generally the extra complications would not be justified.

6.7. The following function procedure will calculate an annuity value for at a rate of interest i. It makes use of the function procedure snc described in 5·2 and as in the case of that procedure if instalments are payable in arrear, the parameter m is set as –m. real procedure an (i, x, n, m); real i, x; integer n, m; comment x is the age after any adjustments; begin real d, j; an: = snc (i, –n, m)+(m+1)/(2 × m); d:=1; if n > 0 then begin for j: = x step 1 until x + n do d:= d/2 × (lpa[j] + lpa[j – 0·5])/(1+i) end; j:=x+n–1; for j: = j+ 1 while lpa[j – 0·5] ¹ 0 do begin d:=d/2 × (lpa[j]+lpa[j–0·5])/(1+i); an:=an+d end end; Use is made of the fact that if j is a real number lpa[j] will be set equal to lpa[y], where y is the integer nearest to j, an exact half being taken up. This enables half-age adjustments to be dealt with relatively easily, although care must be taken with this facility since real variables are not always held exactly. The array lpa is assumed to hold the ultimate values of px, annuitants mortality.

6.8. The first part of question 9 from the Second Paper Part II of the Faculty examinations for April 1968 reads as follows: “A life aged 45 effects a deferred annuity of £100 per annum payable half-yearly in advance from age 65 for ten years certain and life thereafter. Annual premiums are to be paid for a Actuarial Programming Methods 157 maximum of ten years. On death before age 60 the premiums previously paid are to be returned, without interest, by yearly instalments, commencing at the end of the year of death, of amount equal to the premium. On death between age 60 and 65 the reserve held by the life office will be paid. Ignoring expenses and assuming that the reserve and premium bases are the same derive and simplify an expression for the annual premium.” The last sentence of this paragraph might have read: “ . . . write an Algol program to calculate the annual premium, using the procedures snc and an, if the appropriate mortality for the vesting period is held in the form of px in the array lp.” If Rn is the reserve after n years (before any premium, P, due then is paid) the following recurrence relationships will hold:

and since on death between age 60 and 65 the reserve, which is calculated on the same basis as the premium, is paid, The program will then be as follows: begin real reserve, premium; integer totprem, n; reserve: = totprem: = 0; for n:=1 step 1 until 15 do begin premium:=if n 10 then 1 else 0; totprem: = totprem + premium; reserve: = ((reserve + premium) × (1 + i) – (1 – lp[44 + n]) × snc(i, – totprem, 1))/lp[44 + n] end premium: = 100 × an (i, 65, 10, 2)/((1 + i) • 5 × reserve) end; 158 Actuarial Programming Methods 6.9. A more involved procedure than that in 6.7 would be one to calculate an annuity value for ä(m)xat a rate of interest i where if death occurs while the annuity instalments paid are less than the purchase price, the balance is returned immediately. Here an iterative process will have to be used, and it is assumed that the required tolerance tol has been set before entry to the procedure as has the percentage loading, loading, which is used to calculate the gross purchase price. real procedure an2 (i, x, m); real i, x; integer m; begin real lastpp, pp, grosspp, v, d, p, f; integer s; lastpp:=pp:=an (i, x, 0, m); v = 1/(1+i); start: d: = 1; grosspp: =pp/(1 – loading); for s: = 0 step 1 until entier (gvosspp) – 1 do begin p:=(lpa[x+s]+lpa[x+s–0·5])/2; pp:= pp + ((1 – p) × d × v • 0·5) × (grosspp – s – (m + 1)/ (2 × m)); d: = d × p × v end; s: = entier (grosspp) – 1; f:=entier ((grosspp–s) × m); p:=(lpa[x+s]+lpa[x+s–0·5])/2; pp: = pp + (f/m × (1 – p) × d × v • (f/(2 × m)) × (grosspp–s– (f + 1)/(2 × m)) if abs (pp – lastpp) > tol then begin lastpp:=pp; go to start end; an2: = pp/(1 – loading) end; The standard function entier was mentioned in 2·5. Use is made of the fact in the above procedure that entier (x) < x even when x is negative e.g. entier (– 3·7) is – 4. This allows the case of m being negative to be handled without any special adjustment.

6.10. Going on now to the calculation of assurance values the following function procedure will calculate at a rate of interest i. Provision has again been made for an age adjustment in half years but no allowance has been made for claim acceleration. To keep the procedure as simple as possible the complication of a select table has not been introduced but the procedure could be fairly simply adjusted to allow for this; the same applies to the other procedures given in this Chapter. Actuarial Programming Methods 159 real procedure eas (i, x, n); real i, x; integer n; begin integer s; eas: = 1; for s: = n – 1 step – 1 until 0 do eas:=eas/2 × (lp[x+s]+lp[x+s–0·5])/(1+i) + (1 – (lp[x + s] + lp[x+ s– 0·5])/2)/(1 + i) end;

6.11. Supposing now that the rate of interest is assumed to vary from year to year and that the real array i gives the rate of interest applicable to every year, i[t] giving that for the tth year counting from now. This array might have been read in, or calculated from a formula, or in any other manner. Since the rate of interest is varying it will not be possible to calculate from so that to save time we should calculate both at the same time. Since two results will be calculated, it will not be possible to write the procedure in the form of a function which allows only one result to be assigned to the name of the procedure. We will therefore have to use the more general form of procedure and have two parameters, a and b say, which will hold the results.

procedure eas2 (i, x, n, a, b); real array i; real x, a, b; integer n; begin real p, v; integer s; a:=1; b:=0; for s:=n–1 step – 1 until 0 do begin v:=1/(1+i[s+1]) ; p:=(lp[x+s]+lp[x+s–0·5])/2; a: = a × v × p + (1 – p)) × v • 0·5; b: = 1 + b × v × p end end; It should be noted that both these procedures could be used to produce values of Ax (and in the second case äx as well) if n were set ( w – x) but care would have to be taken that the limits of the arrays for the rate of interest and for px were not exceeded. Claim acceleration has been included this time.

6.12. Figure 3 shows the flow chart for a procedure for producing using the immunization approach suggested by Cavaye and Springbett (8) and the procedure itself follows below. In this case the program calculates the critical term t at which immunization can first be achieved rather than have this calculated by hand, making the usual assumption that until this time the assets are invested in 160 Actuarial Programming Methods

Figure 3 Actuarial Programming Methods 161 perpetuities. The procedure assumes that t is the maximum possible value and then reduces it by 1 each time until the smallest integral value of t is found for which immunization can be achieved. It has been written this way rather than starting from the minimum value and working upwards since it is assumed that this procedure will be incorporated in a general program to calculate a whole table of premiums starting at the youngest age and working upwards. If this is the case, the value of t will be reducing from one calculation to the next so that if the maximum value of t is taken as the value found for the last premium, the number of the trial calculations of the premium will be kept to a minimum. For the first entry to the procedure, t will be set as the number of years after which the rate of interest remains constant (since an increase in t beyond this will have no effect on the premium), or the term of the assurance if shorter. The fact that certain expenses are paid at the outset of the contract and not recouped until much later affects the average term of the contract and hence t (8, § 26). For this reason the initial expenses have to be brought into the calculations, and for consistency so have the renewal expenses and the percentage loading of the gross premium. These have been assumed to be located in initexp, renexp and perload respectively.

It will be noted that has been used in place of and in

place of where the unaccented values have been calculated at i and the accented at i-delta, delta having been set to a small value, say 0.000001, before entry. Since t will be taken to the next higher integer, there will be little loss of accuracy, if any.

procedure eas3 (i, t, x, n, prem); real array i; real x, prem; integer t, n; begin real aced, accm, accn, f, p, vl1, vl2, last prem, aval, ann; integer maxt, s; maxt: = t; loop : accd: = 1 ; accm:=accn:=0; for s:=0 step 1 until t—1 do begin p:= (lp[x+s]+ lp[x+s–0.5])/2; f:=i[s+1] x (1+1/i[s+2]); accd: = accd x f x p; accm: = accm x f + (1 – p) x f •0.5; accn:=(1+accn) x f x p end ; 162 Actuarial Programming Methods

eas2 (i[t+1], x+t, n–t, aval, ann); prem: = (aval+accm)/(ana+accn) + initexp x accd/ (ann + accn) ; vl1:=aval–premx(ann–1); eas2 (i[t+1]–delta, x+t, n–t, aval, ann); vl2:=aval–prem x (ann–1); if vl2/vll < i[t+1]/(i[t+l-delta) then begin if t = 0 then go to end; t: = t–1; last prem:=prem; go to loop end; if t < maxt then begin t: = t + 1 ; prem: = last prem end ; end : prem: = (prem + renexp)/( 1–perload) end ;

7. CURVE-FITTING 7.1. The actuary from time to time wishes to construct a mortality table by finding a mathematical curve that will adequately represent his data. He usually starts with a column of exposed to risk and a column of actual deaths (A), each pair of entries being for an appropriate age. When the actual deaths are divided by the exposed to risk he obtains a crude qx (or mx or µx as appropriate). Looked at in one way he has one observation (a value of qx) for each age, and each may be treated as of equal weight. Looked at in another way he has one observation for each person exposed to risk for a year, who has either died (score 1) or not died (score 0) during the year ; in this case the weights at each age may be proportionate to the exposed to risk. Or he may wish to give more force to a ‘reliable’ value of qx based on a large number of deaths than to an ‘unreliable’ value based on few deaths ; the standard errors of the actual deaths may be taken as or just as giving a further set of weights.

7.2. The actuary has some preconceived and necessary ideas about the shape of his curve. It cannot sensibly give a value of qx less than 0 or greater than 1 within the relevant age-range. It should be reasonably smooth and preferably monotonic increasing over the adult ages. Appropriate tests can be devised so that a computer program can reject a curve that does not pass them. A further necessary feature of the curve is that it should represent the data reasonably closely. For this a standard least-squares method is amenable to computer processing. It should also be possible to get the computer to test the curve for adherence to the data and to try again until Actuarial Programming Methods 163 the first satisfactory fit has been achieved. If a curve with n fitted parameters passes a x2 test at a 5% level of significance, then it may be difficult to argue that the (n+1)th parameter really adds much to the accuracy of the curve. But there should be no difficulty in getting a program to fit a series of curves, each with one extra parameter, and give the results of the fit at each stage. The actuary can then choose the one that suits his purpose best.

7.3. At some stage the actuary must choose the shape of curve that he likes best for his data ; but the computer could be asked to provide the results of a number of different possible shapes of curve, applying appropriate tests to each. Similarly the computer can be asked to provide the results of its calculations using each of the possible sets of weights described above. By this time the actuary may be over- whelmed with paper, but he can probably find in it the answer to many questions that begin: “What would happen if I did this:".

7.4. The sort of curves that might be worth trying are: (i) qx = Pn(x) i.e. a polynomial of degree n in z (ii) qx = Pn(x)/Qm(x) i.e. a rational function (iii) qx = Pn(cx) where c is another parameter (iv) qx = Pn(cx)/Qm(cx) (v) log qx = as above for (i) to (iv) or others of further complexity. A polynomial of sufficiently high degree can be made to pass through any set of points provided there is not more than one observation for any one x, but of course it may oscillate wildly in order to do so. Generally, fitted mortality curves have been of types (iii) and (iv), e.g. Gompertz;: µX = bcx Makeham: µx = a+ bcx

Perks:

or:

A1949-52: =

However, mathematical computer curve-fitting has so far concentrated on types (i) and (ii). 164 Actuarial Programming Methods 7.5. The procedure for the fitting of a polynomial is the starting- point from which the other methods lead on. The requirement is to determine the coefficients of the polynomial

such that

is a minimum

where f(xi) is the observed function value for xii (i = 1 to n) and wi is a weight associated with that observation (all the wi may be 1). The solution is obtained by setting the partial differentials

equal to zero, and obtaining a system of m linear equations with m unknowns : CA = R where A is the vector of coefficients, C is the symmetrical matrix with elements

and R is the vector with elements

This gives the solution A = C–1R where C–1 is the inverse matrix of C. This problem can readily be solved by the computer. However, the matrix C is likely to be ill-conditioned—i.e. the determinant is small compared with its individual terms, and the elements of the resulting inverse are inaccurate unless the calculations are carried to a large number of significant figures. This can be improved greatly by using, instead of monomials (xj), Chebyshev polynomials :

To use these, the range and scale of x must be transformed so that it runs from – 1 to + 1 instead of from xmin to xmax, by putting

If the xi are equidistant and the weights are equal the Chebyshev polynomials have the property that equals

0 for j k. We therefore get a diagonal matrix that can easily be inverted. Even if the weights are not equal, or the xi not evenly Actuarial Programming Methods 165 spaded the Chebyshev polynomials help. We obtain the polynomial in the form: and we can use this to calculate the smoothed function values for each value of t.

7.6. An advantage of the Chebyshev polynomials is that as the degree of polynomial is increased, the final coefficients become small if the fit is too good. In the orthogonal case (equidistant xi and equal weights) each added term leaves the previous terms unaltered. But in either case it is possible to calculate after each step the residual sum of squares, i.e. the value of F that we have minimized, and to carry on adding to the degree of the polynomial until the further reduction in F becomes small. Additionally, after fitting each polynomial we can calculate the “expected deaths” and compare these with the actual deaths by a x² test. The printed results after each test would include : (i) the new polynomial of degree m – 1; (ii) an analysis of the original sum of squares, sum of squares attributable to the regression up to m–2, sum of squares attributable to the last term, and residual sum of squares ; (iii) the function values P(x) for each x; (iv) the actual deaths, expected deaths, (A–E), value of x2 and the corresponding probability. The program for this would be too lengthy to quote here, but one procedure required in it is given as an indication of what is happening. It would be called when the xi, f(xi) and wi are decided. It calculates the values of ti, and the elements cjk of the matrix C, and the elements rj of the vector R. Since the matrix C is symmetrical it is economical to store only the upper triangular part in a one-dimensional array, viz:

procedure cheb (x, f, w, n, p, er, xd, x0, c, r, sumsq) ; real array x, f, w, c, r ; real xd, x0, sumsq; integer n, p, er ; comment this sets up the equations of least squares for a given. discrete function in terms of Chebyshev polynomials. The input is given in arrays x, f, w, each of length n, where f [i] is the function value corresponding to the argument x[i] and w[i] is the corresponding weight. If w[l] is 0 then the weights are taken as all 1. The number of Chebyshev polynomials to be used is given in p. The procedure returns 166 Actuarial Programming Methods as output xd and x0, the costants for the transformation of the arguments x into t where t = x x xd + x0. The array c of size p x (p+1)/Z gives the resultant coefficient matrix in a compressed upper triangular form. The array r of size p gives the right hand side of the equations, and sumsq gives the sum of squares of the function values. er is an error marker with value 0 if there are no errors, –1 if n 0 or n>p, and +1 if n = 1, or all the argument values are equal. In all cases the subscripts start at 1; begin real xa, xb, t, T0, T1, T2, df; integer i, j, k, l, m, jj, kk; comment test for errors ; if n 1 then begin er:=if n= 1 then 1 else–1; go to return end ; if n > p then begin er: = – 1 go to return end ; comment now calculate xa = min (x[i]), xb = max (x[i]), and hence xd, x0 ; xa:=zb:=x[1]; for i: = 2 step 1 until n a0 begin if xa>x[i] then xa: = x[i]; if xb < x[i] then xb: = x[i] ; end ; if xa = xb then begin er: = 1; go to return end since all x [i] equal; x0: = –(xa+xb)/(xb–xa) ; xd:=2/(xb–xa); comment now set the first 2p–1 values of c = 0 and all r = 0 and sumsq = 0 ready to calculate values ; for i:=1 step 1 until p do sumsq: = 0 ; comment now for each point up to n calculate Chebyshev polynomials as far as T(2p–1) and multiply these by the weights and store the sums in c[1] to c[2p–1]. Al so calculate r[j] = sum for i = 1 ton of weight x function x T(j–1) for j = 1 to p. Also calculate sumsq = sum of weight x function 2 for all n ; for i: = 1 step 1 until n do begin T0:=1 ; T1:=t; if w[1]>0 then begin T0:=w[i] ; T1 : = t x T0 end allowing for weights ; t:=t+t; sumsq: = sumsq + df x df x To ; m:=p+p–1; for j : = 1 step 1 until m do Actuarial Programming Methods 167 begin c[j]: = c[j]+ T0 ; if j p then r[j]:=r[j]+df x T0 ; T2:=txT1–T0: T0:=T1 ; T1:=T2 end of j loop up to 2p–1 ; end of i loop up to n ; comment now use the relation. 2T(j) x T(k) = T(j+k) + T(j-k) to calculate all c[j, k] starting at the top and working down column by column ; m:=px(p+1)/2; j:=1 ; k:=kk:=p+p–1 ; for jk : = m step–1 until 1 do begin c[jk]: = (c[j]+ c[k])/2 ; if k j then begin kk: = kk–2; k:=kk; j:=1 end to set up next column else begin j:=j+1 ; k:=k–1 end; end of jk loop ; er:=0 return : end of procedure cheb ;

7.7. The next step is to consider the rational expression :

where P(x), Q(x) are polynomials of degree m and l. Again we wish to find values of a0 . .am, b0. . . bi to minimize :

However if we follow the same direct approach we obtain a set of non-linear equations. The problem can be solved instead by repeated approximation. Given an initial approximation P0/Q0 we can obtain a better one by finding P0 and Q0 such that

minimum

We can assume that the constant term of Q (b0) is fixed, i.e. that Q0 has no constant term. We can then expand this expression, ignore terms in ( P)2and ( Q)2 and get an approximation 168 Actuarial Programming Methods This can be transformed further into the form

where

and g*(xi) is an expression with (l+m–1) terms of the form cigi(x) and the cigi(x) are the functions derived from expanding as polynomials P0, and Q0 in F0 above. We now have the same problem as in 7.5 with (l+m–1) unknowns, which we can solve using the same method. Having found P0, and Q0, we can start again with P1/Q1 where

Provided the successive approximations converge we shall reach a satisfactory approximation to the best fit P(x)/Q(x). In practice Chebyshev polynomials are again used, and other refinements are used to assist convergence. Further details are available in the IBM Scientific Subroutine Package (6).

7.8. There remains the problem of deciding how many terms to use in the numerator and denominator. One method would be to find P(x)/Q(x) for all combinations of orders up to some limit, but this would be tedious—even with a computer. An alternative method would be to start with low values, and add another term to whichever of P and Q has the largest final coefficient of the Chebyshev expansion. Another would be to add one term to P and find the reduction in sums of squares ; then instead add one term to Q and find the reduction in sums of squares. The expression that gives the larger reduction in sums of squares is the starting value for next time. This method requires two approximation procedures for each term added, and therefore uses more time than the first alternative. We have not, however, been able to experiment with either method.

7.9. For the actuary the next step is to fit a curve of form (iii) qx = P(cx) or of form (iv) qx = P(cx)/Q(cx). The principle of the first case can be seen from the discussion of the second. It appears to us that this needs to be done in two stages used alternately. Having decided the order of the polynomials P and Q, and chosen a starting value of c, say c0 1, we can first calculate for each xi, then transform these into the range – 1 to + 1 by ti = a . ci+ b. We now Actuarial Programming Methods 169 find the coefficients of P and Q in terms of the Chebyshev expansions to get :

We now replace c0 by c0+ c0 such that

= minimum.

We first use the Taylor expansion to get

where G(c0) = P(t)/Q(t) as above, and

where P', Q' are the differentials of P, Q with respect to ti, and

F has now been expressed in the form

from which we obtain

This gives us our new value c1 = c0+ c0, and we can start the procedure all over again, stopping either when c0 is sufficiently small, or the residual sum of squares is sufficiently small. Again, the procedure can be elaborated so that the program increases the order of the polynomials until a satisfactory fit is found.

7.10. Finally, we can get the computer to check our resulting formula and indicate whether qx goes outside the range 0 to 1 for 0 x 110 say ; whether qx is monotonic increasing ; whether qx is also monotonic increasing ; and indeed give an indication of the first i for which iqx is irregular. N 170 Actuarial Programming Methods 7.11. There may be practical problems in applying these methods ; so far they are only a theoretical approach. The purpose of discussing them in this paper is not to present a new method of curve-fitting, but to indicate an approach to curve-fitting suitable for application to a computer. Further work needs to be done to write the programs and test the methods on practical data ; but once written, the programs themselves are the solution, or the bricks with which to build a solution. 8. NOTATION 8.1. Prom the description of the Algol procedure declaration in 2.14 and the examples given already it must be clear that any actuarial symbol must be converted in a program into a form such as annuity (x, n) or annuity (x, n, k, i, table) where the necessary “ subscripts ” are included in a parameter list in brackets after the function or procedure name. A similar notation is used in all higher level languages. FORTRAN and PL/I have the same form as Algol for a function procedure and also use a form : CALL ANNUITY (X, N, K, I, TABLE, ANSWER) where all the parameters are passed over to a subroutine. COBOL (in the IBM/360 form) uses a similar structure : CALL ‘ ANNUITY ’ USING X, N, K, I, TABLE, ANSWER but has no method of passing over “ global variables ” except through the parameter list. Algol, FORTRAN and PL/I all allow the use of a function procedure, so that one can write, for example : annual premium: = single premium (x, n, i, table)/ (annuity (x, n, k, i, table)) and if i and table are global variables, i.e. are available in the program calling the procedure, we can reduce the procedure calls to : annual premium: = single premium (x, n) / annuity (x, n, k). So far it is not possible to use the same procedure with a variable number of parameters so that calls of : annuity (x, n, k) and annuity (x, n, k, i, table) could use the same procedures with the parameters specified, which failing the currently valid global variables, which failing some default values (such as k = 1). Instead one must define a series of procedures : Actuarial Programming Methods 171 annuity1 (x, n) with k = 1 and global i, table annuity2 (x, n, k) with global i, table annuity3 (x, n, k, i) with global table annuity4 (x, n, k, i, table) with all parameters given. In Algol these could be written so that each procedure except the last set parameters and then called the last procedure, as the most general one, to perform the necessary calculations. In PL/I this can be done by defining separate entry points for one procedure.

8.2. Boehm’s proposals At the 18th International Congress of Actuaries in Munich in 1968 a paper was presented by Boehm and others on Suggestions for an International Actuarial Publication Language and its Representation in Computer Compatible Form (9). This paper had a number of purposes, but the important ones here are the proposals for a Publication Language, suitable for typescript or printing, and a corresponding Computer Language, suitable for use in higher-level languages. The proposals set out a number of rules that are, at first sight, complex, but which could be learnt as readily as the present actuarial notation. In the Publication Language the present value of a life annuity, for instance, is in the form : where the 5 blocks include : the age of the person or persons, e.g. x, or x, y, the period of deferment, duration or other description of the period of payment-this block may be quite complex, the frequency of payment, k, the rate of interest, i, the table of mortality to be used, T. Blocks 4 and 5 may be omitted, if the rate of interest and table are assumed. Similarly block 3 may be omitted if k = 1. Thus we would write in place of the conventional symbols shown : 172 Actuarial Programming Methods Values of single payments are similarly arranged, and premiums can be expressed as, e.g. for an endowment assurance by limited premiums, either P(AE(x ; n) ; ä(x ; m)) or PAE(x ; n; m). In the Publication Language, significance is given to the punctuation (, ; or :) between variables in the subscript part, so that in effect different functions are indicated by this punctuation. In the Computer Language the format of the parameter list has to be described by the function name itself. This is done by a series of alternate alphabetic groups and numeric codes, in a way that is not fully described in the paper. Thus in our examples above we have :

ä(x ; n ; 4; ·03 ; A49–52) not fully defined a(x ; n) AP7(X, N) a(x ; s) AP3(X, S) ä(x ; n1 : n2 ; k) AT5A0(X, N1, N2, K) ä(x : y) AT2Z(Y) – AT3Z(X, Y) (why no single expression?) PAE (x ; n ; m) PAE7C(X, N, M)

8.3. Comments on Boehm’s proposals It is not really possible to do justice to Boehm’s proposals without quoting the paper in full, and it is clear that even the paper does not cover fully all the possibilities that the authors must have considered. Their proposals would lead to a more powerful and explicit way of describing many functions that are obscure, or impossible, with the present notation. They introduce many desirable alternative forms (e.g. a (x ; n) for annuities with a fixed term and a (x ; s) for annuities with a fixed terminal age). They allow the rate of interest and the table of mortality to be included as explicit variables. They replace the Greek w by a w ; but they allow certain other Greek letters. They get rid of the swarm of indices that cluster around a central symbol. They get rid of superscript - and 0 ; but not ä (an acceptable German letter !—why not use its equivalent ae—or ad for annuity due ?). Indeed generally their proposals for a Publication Language are worthy of very serious consideration. However we feel that there are still disadvantages in the Computer Language :

(1) It is not clear whether the terms are intended to be function procedures or subroutine procedures. They are probably function Actuarial Programming Methods 173 procedures of an Algol type with the rate of interest and mortality table as global variables. If so, (2) They do not state the form in which the mortality table is assumed to be given. Is it a table of l(x) or of q(x) or of p(x) ? A different procedure is necessary for each of these cases. Similarly, a complete suite of different procedures is necessary for select tables (the authors recognize this). Alternatively, (3) Are commutation tables of some form assumed as the basis, and in what form are they given? (4) The function procedure produces a single value, It may be desirable in a practical case to store an interim table in working storage. One would like a procedure to calculate a table of ä (x, n) for x from x1 to x2 and for n from n1 to n2. This could be declared in Algol as array tat7[x1 : x2, n1 : n2] and could be filled with calculated values perhaps by :

for x: = x1 step 1 until x2 do for n: = n1 step 1 until n2 do tat7 [x, n] : = at7 (x, n) ; but this is possibly very wasteful of computer time, since each value of at7 (x, n) has to be calculated from first principles. More economical would be a procedure statement :

fill tat7 given N (tat7, x1, x2, n1, n2, N) where the procedure name is “ fill tat7given N ” and the parameters are the arrays tat7 and N (i.e. a commutation table of Nx), and the integer limits x1, x2, n1, n2. It is clear that a large repertoire of “ fill X given Y ” procedures would be needed to cover all likely cases, and their names, though explicit enough, are perhaps rather cumbersome -indeed are too long for implementation by some compilers. (5) The same names are used for single life and for joint life functions. Within one program it may be necessary to distinguish L(x) Male, L(y) Female, and L(x, y) Joint. Different names are therefore required, such as L, LY, LXY. These objections, however, do not mean that the authors would like to see Boehm’s proposals dismissed or ignored. They form the first draft of what, in our opinion, is a necessary and inevitable change in actuarial notation, which should be considered in greater detail by the Faculty.*

* (Note : it is hoped to publish a translation of the paper by Boehm et al. in T.F.A.). 174 Actuarial Programming Methods

9. COLUMN-PROCESSING LANGUAGES 9.1. Since a great deal of actuarial calculation can be expressed in the form of operations on columns of numbers (or vectors, or one- dimensional arrays) it is natural that some developments have already taken place towards a column-processing language. In the early days of computers a “ Matrix Interpretive Scheme ” was written for use on Ferranti computers including Pegasus. This was not a compiler, but an interpretive scheme, whereby each instruction was interpreted and then obeyed. It was limited in its power and slow in operation, but it did allow statements such as

A = B+C A = B×C A = B* i.e. A = transpose of B A= k × A where A, B, C were matrices, and k was a scalar applied to each term of A. However, multiplication in this scheme was matrix multiplication, and not a(i, j) = b(i, j) × c(i, j) which is what is required in actuarial work. Algol, at present does not allow array arithmetic directly. One cannot say, for example :

array a, b, c, d ; c: = a × b termbyterm ; d: = a × b matrix ; where termbyterm and matrix distinguish the two kinds of operation. PL/I, however, does allow the former (termbyterm) version. Sub- routines for matrix arithmetic are available in FORTRAN as mentioned in 3.6, and no doubt array arithmetic could be dealt with similarly. A disadvantage of FORTRAN (and COBOL) for actuarial purposes is that the subscripts for all arrays start at 1, so one either has to reserve a great deal of unused store, or remember that l[1] really means l15 say. This restriction does not apply to Algol or PL/I.

9.2. The Benjamin package Two further papers at the 18th International Congress of Actuaries described column-processors of different types. The first was created and described by S. Benjamin (10) and is essentially a set of procedures or package that can be inserted at the head of a program in Actuarial Programming Methods 175 order to facilitate the manipulation of columns. Although the package is in fact written in Extended Mercury Autocode it is described in the paper in Algol. It allows and requires columns to be numbered (which has advantages and disadvantages) and the columns are further defined by a first age and a last age. The procedure : set up (col no, first age, last age) ; is the equivalent of a declaration of that column, with stated first age and last age, and an alternative procedure set (col no) ; where first age and last age have been set already in the program, allows a column to be input which has its first and last ages as the first two items in it. Triangular tables (or rectangular ones) can be set up by an appropriate loop, varying co1 no and if required one of the ages. The package includes a number of standard functions ; among those quoted are colmult (n3, n1, n2), sumup (n4, n3) which is the last age equivalent operator to f(i) (x = first age to last age), and vcol i = x (col no, i) which calculates v first age,...v last age for rate i ; there are presumably many more. It also includes (in the E.M.A. version) useful input and output procedures, and the power to call a named table from a library. If published in full in an Algol form, Benjamin’s package would provide a valuable basis on which other facilities could be built. Indeed, what has already been published is a useful start for anyone considering the development of such a package. It would seem to the authors that useful extensions might include the facility for using named columns as well as numbered ones, for allowing more than one series of numbered arrays, and for performing some arithmetic on rectangular arrays, or triangular ones (or perhaps trapezoidal ones). It might also be useful to perform operations on columns with an offset age, a facility available in AKTUARIAT, to be considered next.

9.3. AKTUARIAT 9.3.1. AKTUARIAT was developed at Berne University as a single program for use on a Bull-GE Gamma 30 S computer. A paper describing it was presented by Kunz (11) to the 18th International Congress of Actuaries. It provides, within a rigid format, a series of instructions of considerable power suitable for column-processing. 176 Actuarial Programming Methods It resembles more closely an assembler language with very powerful instructions than a higher-level language. The storage available appears to be pre-formatted into 100 fixed columns with names KT00 to KT99, each of which may run at most from “ age ” 0 to “ age” 117. There are also 100 fixed scalars with names WE00 to WE99, and 100 index registers with names IR00 to IR99. Further columns can be placed in a magnetic tape store and referred to by the number of the tape-unit and a name from ST00 to ST99.

9.3.2. There are 27 instructions, each with its own fixed format. The principal arithmetic instructions are ADD, SUB, MUL, DIV, SUMM

PIMUL (b(0) = k, b(t) = b(t-1) × a(t), where a and b are columns, k a constant), and INTPOL (Interpolation). Each of these requires three operands, i.e. is of the form

OP3 = OP1+OP2 (termbyterm), where OP3 is a KT value, and OP1 and OP2 either KT or WE. The age limits (XO and XS) are also stated in the instruction format, together with an age difference, _+ d, that can be used to offset the column in OP2 against OP1 and OP3.

9.3.3. The index registers allow us the same facility as a for...do loop in Algol, and each of the operands (XO, XS, ± d, OP1, OP2 and OP3) can be indexed (or modified) independently. One branch instruction is available, equivalent to IRxx: = IRxx—1 ; if IRxx ± 0 go to label ; which is required for counting in loops.

9.3.4. An AKTUARIAT program is compiled and run under the control of a monitor program, which checks the input cards for correct format, as does any compiler, but which also monitors the program during execution, looking out for any errors such as dividing by zero or using ages out of range, and gives appropriate diagnostics and partial results in the event of a failure. This helps when developing and testing a program. A middling complicated program of 100 instructions, it was quoted, required about 3 hours to write, 1 hour to test with two machine attempts, and 1½ minutes to run. The input was a table of qx and the output was a mortality table with the usual Actuarial Programming Methods 177 set of functions, and for each of 13 rates of interest commutation tables, äx, Ax, Px, and ä(x ; n), the last at quinquennial points.

9.3.5. AKTUARIAT certainly appears to have much of what an actuarial department would like, but it, has a number of disadvantages:

(1) It is so far tied to one machine. (2) Alterations and extensions would require detailed programming, by those familiar with the compiler/monitor. (3) It cannot be used in combination with other higher-level languages. (4) It cannot be used to construct subroutines for insertion into a master program in another language. (5) It does not have the same advantages as Algol as a medium of communication. (6) It is short of if-type instructions and lacks Boolean variables. (7) It does not appear to have the facility of including already written procedures except by copying a block of existing cards externally.

Nevertheless, it is the most ambitious attempt so far recorded to provide a special-purpose actuarial language, and for this reason alone its features deserve wider study and wider practical use.

9.3.6. One method of developing AKTUARIAT for wider use would be for the program to be rewritten for use on a variety of other computers. The specifications, format, and much of the internal logic would be valid on any other machine. But this would involve a considerable task in reprogramming. Another method would be to develop macro-instructions within the existing assembler languages. This again would require reprogramming for each assembler language used, but it would allow the facility to include ordinary assembler language instructions as well as the AKTUARIAT ones, and also the facility to invent new macro-instructions as desired. It would also allow AKTUARIAT programs to use subroutines written in another language, or with care allow another language to use an AKTUARIAT subroutine. It would be going into too much detail in this paper to give examples of how these macros could be written, and it will have to suffice if we explain for example that the macro- instruction

ADD x0, xs, op1, op2, op3, D = d, IR01 = i, IR03 = j 178 Actuarial Programming Methods

would generate the appropriate assembler language instructions to perform the addition of column (op1+i) to op2 offset by d years, putting the result in (op3+j). The first and last ages for (op1+i) and (op3+j) are x0 and xs, and the first and last ages for op2 are (x0+d) and (xs+d). The program might begin and end with macros : AKTBEGIN AKTEND

which would reserve storage, generate the necessary beginning and ending assembler language instructions, and provide calls to any special purpose subroutines needed. A disadvantage of the macro system is that the monitor program would either not be present, or require rather elaborate programming within the macros themselves.

10. CONCLUSION 10.1. The authors of this paper had several too ambitious aims in mind when they began to write it. They were : (a) to introduce to members of the Faculty a higher-level programming language, and to show that such a language is a convenient and elegant way of expressing calculations, and that the program is in itself the solution to certain types of problem ; (b) to show the program-solutions to a few actuarial problems, in sufficient detail to demonstrate to others exactly how similar problems could be tackled, thus encouraging the development and publication of a series of actuarial algorithms ; (c) to show how the use of programming methods could be related to the examinations of the Faculty at a number of stages, and to suggest that any future alteration of the syllabus could take account of this ; (d) to bring to the attention of the Faculty the necessity of reconsidering the international actuarial notation so as to provide a recognized alternative notation for use in programs ; (e) to suggest ways in which the use of computers could further the development of certain actuarial techniques. With so many different targets to aim at, it is not surprising that we have fallen short of all of them. We suffer from the disadvantage -in common with almost all other actuaries-of not having studied mathematics at school in accordance with the new methods, and from the further disadvantage-but here many actuaries are better placed than we-of not having university degrees in mathematics. Our Actuarial Programming Methods 179 knowledge of many fields of modern mathematics is therefore rather like the result of a child with a tin of paint-we have dipped in, and emerged rather speckled, with what has stuck being in the wrong places. Nevertheless, we hope that our brief tour of some numerical and computational methods has been neither too naïve for the initiated nor too involved for the novice, and that our tentative footsteps towards actuarial programming will encourage others to tread more firmly along the path.

10.2. Finally, we should like to acknowledge with gratitude the assistance and encouragement given us by Mr. A. P. Limb, M.A., F.I.A., and Mr. E. C. Morrison, M.A., F.F.A. in our earlier discussions on this subject.

REFERENCES 1. EKMAN,T. and FROBERG,C. E., Introduction to Algol Programming, Oxford University Press, 1967. 2. DIJKSTRA,E. W., A Primer of Algol 60Programming, Academic Press, 1962. 3. BULL,G., Computational Methods and Algal, Harrap, 1966. 4. HAWGOOD,J., Numerical Methods in Algal, McGraw-Hill, 1965. 5. HART, J. F., CHENEY,E. W., et al., Computer Approximations, John Wiley, 1968. 6. System/360 Scientific Subroutine Package, IBM H20-0205-3, 1968. 7. The Construction and Description of Algorithms, Applied Statistics, Vol. 17, No. 2, p. 175, 1968. 8. CAVAYE,C. M. and SPRINGBETT,T. M., Actuarial Note, T.F.A. Vol. 28, p. 308. 9. BOEHM, C., REICHEL, G., et al., Vorschläge für eine internationale versicherungsmathematischeVeröffentlichungssprache und ihre computer- verträglicheDarstellung, Transactions of the 18th International Congress of Actuaries, p. 815. 10. BENJAMIN,S., A language for routine actuarial programming, Transactions of the 18th International Congressof Actuaries, p. 771. 11. KUNZ,P., Die Programmierung AKTUARIAT, Transactions of the 18th International Congressof Actuaries, p. 931. 180 Actuarial Programming Methods

SYNOPSIS

Little has been written about the ways in which computers can be used to deal with specifically actuarial problems, as opposed to data processing ones. The development of “ higher-level ” computer languages has enabled algorithms to be written in the form of programs which are reasonably intelligible, and with the use of one such language, Algol, the paper sets out to show how a variety of actuarial problems can be tackled. Section 2 describes Algol in sufficient detail for the programs shown in the paper to be understood. Numerical Analysis is discussed in Section 3, which gives algorithms for some problems in Finite Differences, and Section 4 suggests the kind of program subroutines that may be required for statistical work. Part of the present Faculty Part II syllabus is dealt with in Sections 5 and 6 while Section 7 discusses the use that could be made of modern mathematical techniques, with the aid of the computer, in the problem of curve-fitting. Section 8 deals with the question of up-to-date actuarial notation and in Section 9 reference is made to two special column-processing computer languages, specially written for actuarial work, which are in use at the present time. Actuarial Programming Methods 181

DISCUSSION Mr. E. S. Robertson, introducing the paper, said :—As implied in Section 10.2 this paper was the outcome of discussions which we had with Messrs. A. P. Limb and E. C. Morrison on the subject of higher-level computer languages and the ways in which these languages could be used to express actuarial calculations At the end of these discussions, Mr. Wilkie and I considered that there might be sufficient material for a paper to the Faculty on this subject, and that such a paper might produce a worthwhile discussion. We hope that our optimism has been justified. We would like to make it clear that the opinions expressed in the paper are entirely our own. We would also like to emphasize that the programs we have given are not necessarily the best solutions to the problem. We believe that more use could be made of higher-level computer languages—not necessarily Algol—in actuarial work where results are not required with great frequency, and if our paper arouses an interest in these languages in some not already familiar with them, we shall be happy. In conclusion, may I express our deep appreciation of the honour the Faculty has done us in allowing us to present this paper to you. We are looking forward very much to the discussion.

Mr. A. P. Limb, opening the discussion, said :—The authors of this evening’s paper have put the Faculty and the profession in their debt. Since commercially-available computers first engaged actuaries’ attention some ten years or more ago, study has naturally been concentrated mainly on those areas where the computer’s capacious memory, its remarkable propensity for accurate arithmetic and its rapid data-processing powers indicate that it can clearly be usefully employed. This has meant, for the life offices, such tasks as valuation, the production of renewal debits, accounting for payments received, authorizing commission and annuity payments, production of statistics and various other applications with which we are all familiar. One would feel, and studies made have confirmed the impression, that early concentration in these areas was necessary to exploit the computer economically. Yet each of us must have felt, when thinking of the future impact of the computer on the profession and on our daily work—I hope I may be for- given for misquoting Rupert Brooke :— “These tasks cannot be all, I’m sure, For how prosaic if they were.” Our authors tonight have addressed themselves to this implicit question and glimpse, as possible future developments, the diminution if not the complete obliteration of certain areas of actuarial drudgery, a modification of actuarial training and examinations and the birth of a new actuarial language. This paper is not however limited to a description of what the future may hold—a bold and dangerous undertaking—but serves also a very practical, and most useful, purpose for today. It describes in detail how a computer would be instructed to perform certain specific actuarial tasks. Within a brief compass it provides information which will be of interest and value to those actuaries whose work does not bring them into close practical contact with a computer. For all these reasons I congratu- late the authors on their most valuable paper. 182 Actuarial Programming Methods In outline the paper really consists of three parts. In the first, computer languages are discussed and a fairly detailed description of one such language, Algol, is given. In the second, various applications of actuarial interest and use are set out, fully illustrated by extracts from Algol programs. This second part of the paper, the largest, includes Sections 3 to 7 of the paper, under the headings numerical analysis, statistics, compound interest, life contingencies and curve fitting. The third and final part of the paper tackles the question of the impact of the computer on current actuarial notation, and the development of actuarial programming languages. It is well known that each type of computer has its own language or order code, which is a function of the machine’s circuitry, and into which all instructions must be translated before the machine can operate. It is equally well-known that these machine languages are extremely impractical and inconvenient to use, and programmers require, for numerous reasons, a language freed from the idiosyncrasies of any particular computer and designed from a logical rather than a technological standpoint. The various so-called “high-level” languages mentioned in the paper are attempts to satisfy this need. They can exist because all machine-languages have essentially the same logical grouping of order codes. The exact details of the language vary from computer to computer, but the logical functions performed can be classified in a common way, and this logical content is exhibited of course by all high-level languages, including Algol. A word of warning, alas, is necessary. The attempt to develop a single universally acceptable language has so far failed. PL/I, mentioned in the paper, is a hopeful candidate for this prize, but shows few signs as yet of obtaining it. The position at present is fluid with some languages suitable for some tasks, and other languages for other applications. Furthermore there is a loss of efficiency in translating a high-level language to a form the computer can comprehend. Finally, programs written in a high-level language for one machine may well be inefficient on another because of design differences and this matter is sometimes serious from a financial point of view. Thus the appeal of high-level languages is a little tarnished. The language chosen in this paper would certainly not be used for anything but a minute part of any life office work as the paper acknowledges. Why then should actuaries direct their attention to a computer language which would not be used for the bulk of life office work if at all, and which, in the words of the authors, “has very poor character-handling and file- processing facilities?” The paper suggests that it is a powerful and elegant mathematically-oriented language suitable for expressing the essentials of the type of calculation with which the paper is concerned, and with this I entirely agree. The paper goes on to assert, and I quote, that “those concerned with computers have discovered that a ‘program’ in a high- level language can specify what has to be done in a given calculation more precisely and more explicitly than an explanation in ‘ordinary language’.” I assume that by ‘ordinary language’ the authors include not merely Queen’s English, but also the conventional mathematical and actuarial symbols using which calculations are normally specified. This assertion that Algol may be more suitable than such conventional symbols is very provocative and, if true, very important. I must say plainly then, that in my view it is not true that Algol, or any other computer language I have met, is more precise or more explicit than normal mathematical or actuarial symbolism for specifying calculations. Moreover, I find Algol much less readily comprehensible. I should at once Actuarial Programming Methods 183 admit that I had not, prior to reading this paper, examined Algol, but in defence of my point of view perhaps I may be permitted to add that over the past ten years I have studied six computer languages, including two high-level languages, in sufficient depth to realize that their logical essentials are common. It seems to me therefore that it is a matter of opinion, rather than established fact, whether Algol should be studied on the grounds of superiority for use in specifying calculations. Nonetheless there is, I think, an excellent reason for examining this language. It exhibits the essentials of the way in which a computer is used to perform computations. There is no doubt in my mind that actuaries gain by being acquainted with these techniques. Much of an actuary‘s specialized knowledge consists of computational procedures, often on very large bodies of data. The computer is well fitted for such computations, and the actuary should be able to recognize the machine’s limitations and possibilities: the achievement of such a position is assisted by understanding how the computer performs. Such an understanding is not in my view essential to the actuary, but it does help him, and this paper provides that knowledge. The authors have given an excellent explanation of Algol and their numerous examples of its use seem to me to avoid the traps both of excessive complication and of irritating triviality. I turn now to the second part of the paper where applications, all of actuarial interest and some of actuarial usefulness, are discussed. The distinction between academic interest and practical use seems to me to be an important one when the final part of the paper is being considered. Almost the whole of the section of the paper dealing with Numerical Analysis seems to me to fall into the former category. It can be but rarely, if at all, that the overwhelming majority of us have occasion in our professional life to solve a set of simultaneous equations, to perform an approximate integration or to calculate an exponential. I am not suggest- ing for a moment that it is unnecessary for us to be able to do these things or that those parts of our examinations dealing with them should be abandoned. They help in the development of logical thinking, a feeling for numbers and are part of mathematical literacy, but as specific operations they are of little everyday practical use to us. Nonetheless, it is of interest to see how these problems would be tackled using a computer, and standard programs to perform these tasks are usually prepared by a manufacturer, though not always written in a high-level language. Only the section dealing with finite differences and interpolation is of direct actuarial use under the heading “Numerical Analysis”. The authors envisage the possibility of there being made available to all actuaries, over a period, a library of standard actuarial procedures, and the paper attempts to suggest, by way of the illustrations used, the kind of procedures which might well find their way into such a library. I think that the idea of such a library has great merit, and I shall return to it, but I am very sceptical of the value of having available, for example, a suite of programs dealing with finite differences and interpolation. Such problems arise rarely, each is different from its predecessor, and when the problems do arise the solution is often required swiftly. It seems to me that, to look at the matter from a practical viewpoint, the time and effort required to devise a solution to the problem by searching through the specification of available procedures, combining them as required and submitting them to a computer would far exceed the time and effort required to solve the problem using a hand calculating machine and a little cunning. 184 Actuarial Programming Methods The section of the paper headed “Statistics” is brief, and again, except for the paragraph on mortality statistics, is of academic interest rather than practical use for an actuary. Graduation methods seem to. offer a field where the computer can be of great value to an actuary. Moving now to the subject of Compound Interest and Life Contingencies we reach areas where the computer has already relieved actuaries and others of much tedium. Most life offices will use daily compound interest and other tables prepared by computer, and will calculate most sets of premium rates using a computer. These are subjects which are un- questionably of great practical value. Building Societies no doubt calculate repayment schedules electronically much as the paper describes and stockbrokers certainly use the machines to produce redemption yields and other data. The authors modestly suggest that there may be better ways of performing some of the calculations illustrated than those they indicate, but the beauty of the computer is that, unless a calculation is to be performed very frequently or is extremely long and repetitive, it is quite unimportant to search for elegance and economy when writing a program. The first simple and convenient method one thinks of will do very well for a premium rate program, for example, even to calculate annuity rates in the present troublous times! I deprecate, however, any suggestion that a computer would be used to solve isolated and peculiar problems of the type that figure in examination papers in compound interest or life contingencies. Nor do I like the notion of asking students to produce computer programs, or even fragments thereof, in answer to examination questions. In the first place I think the answer can most readily be put using conventional notation. Secondly, if students are to be required to display knowledge of a computer language then such knowledge would best be tested, in my view, as a separate subject, using as examples situations where a computer would in practice be employed. Finally I am not convinced that it is necessary for students to acquire such detailed knowledge. They should certainly learn when to use a computer, and understand its advantages when a large volume of data is to be processed or a large number of repetitive calculations is to be performed. I would agree that a particular language should be learned if I felt it had marked advantages over other notations, but as I have indicated I do not believe this to be the case, so that in my view a passing acquaintance with computer languages, such as can be obtained by reading this paper, is enough and need not be examinable. The section on Curve-Fitting I found particularly interesting. F. M. Redington in his recent paper to the Institute entitled “An Exploration into Patterns of Mortality” observed that much of the calculation had been done by hand and added, I thought a trifle regretfully, that no doubt future researchers in the field would rely on a computer more heavily. He remarked that he feared that the computer might have the same effect on our minds as the motor car on our bodies but I think this an unduly pessimistic prognosis. A good deal of work has already been done on mathematical computer curve-fitting, and I would like” particularly to mention R. C. Llovd‘s paper, J.S.S. vol. 17, part 5, as being of specific actuarial interest and usefulness. The paper before us tonight deals with curve-fitting using polynomial and other functions. In my own office we have done some experiments using a polynomial function with a somewhat simpler approach than that outlined in the paper. Early results, using large bodies of data which were nearly smooth before the curve was fitted, were encouraging, but later experiments, using much scantier data with Actuarial Programming Methods 185

grosser fluctuations to be smoothed out, have proved disappointing. The least-squares procedure is not, apparently, mathematically equivalent to the tests an actuary applies to a graduation, and this may be the root of the difficulty. Whatever the reason may be it would appear that least-squares polynomial approximations to mortality curves arc unsatisfactory over large age-ranges, even polynomials of the complexity which could not be contemplated without a computer. Successful work appears to require rather more sophisticated curves and the use of actuarial tests within the procedure. The final part of the paper deals with actuarial notation and with attempts that have been made to provide specifically actuarial procedures and languages to date. What is described in the paper as the Benjamin package could well, if published in Algol, form the nucleus of an actuarial library. AKTUARIAT is an attempt to provide an actuarial language, which is a very ambitious project. As the authors point out it is so far limted to one computer and one cannot easily foresee the provision of compilers to enable it to be used on other machines. This seems to me to be a much less practical approach than the use of an existing high-level language. On the question of actuarial notation, illustrated by a discussion of Boehm’s proposals made at the 18th International Congress, the authors say that in their view these proposals “form the first draft of. . . a necessary and inevitable change in actuarial notation, which should be considered in greater detail by the Faculty”. Why should we think of changing our notation? It is asserted first that our notation is inept at expressing some functions which have thus to be explained and defined when they are used. Then again, our current notation, with what the paper calls “the swarm of indices that cluster around a central symbol” is difficult to print. Finally our notation does not lend itself to computer usage. I would like to answer these points. As I see it, our notation is perfectly adequate to express the majority of actuarial ideas in current use: if a symbol has occasionally to be defined it is not significant. Secondly the difficulties in printing have been consistently overcome for many years, and I personally find a central symbol, albeit surrounded by a swarm of indices in conventional locations, easier to remember and understand than a string of symbols. Finally the incompatibility with high-level computer languages is important only if their usage should become general amongst actuaries, and as I have already said, I do not expect this to happen. One may add that the enormous problems which would arise amongst existing actuaries, published work, textbooks and so on were a new notation to be introduced are so daunting that major advantages must be seen to be ensured before notation is changed: I do not see such advantages. Nor an I attracted by the possibility of two, or more, notations being used concurrently. It may well be that change in current notation is needful, but it should take the form of a refinement of current symbols, not their replacement. In reading the list of aims the authors had in mind when they began to write the paper, one realizes how very thoroughly and excellently they have accomplished their task. Their introduction to Algol and illustrations of its use seem to me to be admirable and will surely be most useful to students and enthusiasts. I hope that it will encourage the gradual accumulation of an actuarial algorithm library and I would suggest that this can best be accomplished by the publication as appendices to papers, in a high-level language and working form, of programs authors may have O 186 Actuarial Programming Methods developed in writing their papers. The necessary actuarial development, in conventional symbolism, would be in the body of the paper. The authors have demonstrated how the use of programming methods could be related to Faculty examinations: for my own part I do not think this desirable. The possibility of reconsidering international actuarial notation will no doubt give rise to discussion this evening, as the authors wish. The author’s final most tantalizing and ambitious aim was to suggest ways in which the use of computers could further the development of certain actuarial techniques. The paper “Putting Computers on to Actuarial Work” by Sidney Benjamin presented to the Institute in 1966 had a broadly similar aim and the authors are to be congratulated on having very largely explored different, possible future developments. For my part I think that the future exploitation of the machine by actuaries will centre on its data-processing facilities, such as are used in valuation techniques, but its calculating powers, as in graduation methods, will find further out- lets too. A further type of application which I find particularly intriguing, and which is being explored by actuaries in various parts of the world, relates to simulations of life office experience, under various assumptions concerning new business levels, interest rates and so on, in a probabilistic environment. At present I have reservations about this kind of exercise: it is easy to formulate the variables one wishes to take into account and the situations one wishes to explore, but the labour involved in preparing the programs is immense and costly; and the end results, if they are to be used in practice, depend on subjective judgement concerning the degree of risk an office can run and the confidence with which particular values of the several variables may be used. In the end, caution allied to quite simple models may be more useful. I would like to end as I began, by expressing our thanks to the authors for their provocative, imaginative and thoughtful paper.

Mr. G. D. Gwilt.—The problem behind tonight’s paper is one of communication between actuaries and computers. The preparation of any task for a computer involves the three stages of job analysis (the specification of the work to be done by the computer), systems analysis (the invention of the method by which the computer will do the work) and programming (the writing of detailed instructions to the computer). The problem is how to reduce the time taken by these three stages. I would prefer to think of actuaries reaching for their terminal typewriters rather than for their Brunsvigas, but this will not be possible until the communication time lag has been reduced or eliminated. Incidentally the instant use of a set of algorithms sitting inside a computer becomes feasible with terminals. A high-level language is a help mainly to the programmer in that it reduces the amount of coding and results in a ‘grammatical’ machine code because much of the work has been done already and is latent in the compiler. Incidentally I think it should be plainly stated that the primary purpose of a high-level language is to help the programmer. If it is also comprehensible to a non-programmer so much the better. But although I could, with some effort, understand what an algorithm is doing I could not, as a non-programmer, write an algorithm; I would get the commas in the wrong places. The work of systems analysis is speeded for particular cases if a scheme has been worked out beforehand and programmed in advance. An example of this is the set of IOCS (Input/Output Control System) routines Actuarial Programming Methods 187 supplied by IBM which amongst other things enable records to be read from files held on disk, tape, cards, etc. merely by issuing the command GET. This will work of course only if the file has previously been defined in the program. At a different level large programming systems such as ALIS (supplied by IBM for the maintenance and use of a complex file of particulars of life assurance policies) or RIVAL (produced by ICL for help in valuations) provide very substantial aid to systems analysts. In the case of job analysis too, it is possible to save time by having already done the work, by having answered in advance all the questions which may ever crop up. Perhaps I might take the example of a task of calculating premium rates for group pensions. Such rates involve annuity values and the type of annuity specified by the job analyst was without proportion, monthly in advance with five year guarantee. Good programmers never fully believe what they are told and being assured that the five year guarantee might in some cases be a no-year guarantee but would never be fractional the programmer concerned produced a program which would calculate annuity values with non-integral terms certain. Sure enough, a request finally came through for a term certain of 2·6 years. However it also became necessary later to amend the program to include such cases as quarterly in arrear. Indeed for another program an unwel- come distortion appeared in a table of rates because the term involving µ and d had been ignored. Also annuity values with proportion are sometimes required. It is in fact difficult for the job analyst to decide in advance how general his specification should be. It is also difficult for the systems analyst (or programmer) to decide how general to be. In Section 6.7 the authors give an algorithm for such an annuity value as I have mentioned. I think (I am not sure that I understand the algorithm correctly) that this formula does not involve the µ and d term. Nor does it give the option of with proportion. The term certain, too, must be integral. Alas, that algorithm would not have been general enough. Section 7 deals with curve-fitting. In this connection it might be interesting to note that an algorithm mentioned in the Computer Journal vol. 12, no. 1, February 1969 fits g(x) to a + be–cs by least squares. This curve is of course, Makeham, if c is negative. I agree with the authors that a list of suitable actuarial algorithms should be published by the Faculty.

Mr. N. S. Hermiston.—There has been a mention this afternoon of a new actuarial programming package—“RIVAL” (Rapid Insurance Valuation Language) which has just been released officially by ICL. The use in Scotland of this new language, has, as far as I know, been limited to one office and I feel that an outline of the new system from the point of view of a user might be of some interest as an addition to this afternoon’s paper. As its name implies the purpose of RIVAL is to provide a means of carrying out a valuation on a computer with a minimum of time and effort on any required basis. A valuation using RIVAL consists of several steps, the first of which is to prepare parameters which request the required commutation columns and also to prepare the formulae for each valuation class. The preparation and layout of these parameters and formulae is in fact the RIVAL language—this is a very simple process requiring absolutely no programming experience (the main advantage of RIVAL). The next step is to read the RIVAL formulae into the computer, subject them to a very thorough validation and calculate the required commutation 188 Actuarial Programming Methods columns. Finally the formulae are compiled into a series of overlay programs—one for each valuation class—each containing the commutation columns which it requires. The main calculation run then takes place by running the overlay programs against a file of valuation data (in a specific format) and writing the results to an output tape for processing by user programs. The RIVAL package is therefore extremely powerful in its own field— but is very inflexible when compared with FORTRAN, Algol and other mathematical programming languages. In fact RIVAL is not a language in the same sense as FORTRAN, etc., but merely the way of supplying a particular suite of programs with the appropriate information. In the paper it is stated that valuations by Computer have in the past been carried out by the first convenient new method that came to hand. This charge could possibly be levelled against our own approach except that the first method—RIVAL—was capable of net premium or bonus reserve valuations by individual policy or group of policies, because it was developed to our specifications. Another point to be taken into consideration was the considerable amount of programming effort which was not required due to the avail- ability of the package. RIVAL has also been used with considerable success to calculate premium rates by considering each rate as an individual record to be valued. On the whole therefore, the system has been of considerable value, and has saved—in addition to systems and programming work—a large amount of clerical effort in the fields of both valuation and premium rate calculation.

Mr. N. G. Thomas.—The authors regard it as virtuous, although they imply that it is impractical, to use Home products. It was rather because Extended Mercury Autocode is the only mathematical language available on my Office’s computer, that I have been using it to write actuarial programs. Before using it I learned a little FORTRAN at some evening classes, and was then taught to program in a low-level language. Although I haven’t written a great deal in this language, I think the training was useful because it enabled me to understand compiled programs, and to appreciate what happens when a program is compiled. In this way I think I was able to use the high-level language more efficiently. My work has mostly involved programs to calculate rates of various sorts and functions involving compound interest and life contingencies for valuation purposes. I have also been planning a system of valuation not unlike the ICL package called RIVAL which has received some publicity recently. I was therefore particularly interested in the sections of the paper dealing with compound interest and life contingencies. Undoubtedly any Institute student will find the paper an invaluable asset, particularly those taking the parts requiring a knowledge of Algol. The authors mention that it is included in I(l), but it is also required for I(2) and I do not think it will be long before this is extended to others. I think the authors are to be congratulated on this valuable addition to the course of reading. They do not claim that their algorithms are in any way the best, but all students and programmers must have welcomed the chance to compare their methods with those in the paper. I was interested to read at the beginning of the life contingencies section, that the authors recommend the use of only one commutation function N. This follows the same idea as used in RIVAL. When writing Actuarial Programming Methods 189 relatively small programs in EMA however, the compiler requires 5,000 words, or units of storage, and so there is no need to be economical below that level. I usually store l’s v’s. D’s and N’s in one dimensional arrays. I have always input a table of l's, although I take the authors’ point concerning q’s. Having recommended the use of N’s, the authors then seem to ignore them in preference for the more basic p’s and q's, presumably because of the problem of varying rates of interest. I am not convinced that algorithms should be quite so basic as this and have usually found that tailor made programs are easier to write and more satisfactory in general than those consisting of standard packages. In a paper of this length, one hesitates to suggest that the authors should have included more examples, but not too long ago I wrote a program to calculate contingent assurances and noticed that here was a good example of where computers lead us to re-think. It would not have been difficult to program Hardy’s 39a, but it was even simpler to define a suitable commutation function and sum for all ages. Another program I recently wrote was one to calculate a variety of annuity rates, including some rather complex longest life rates with a guaranteed term and an unusual mortality adjustment, and some of the type described in Section 6.9 where the balance of purchase price is returned on death. I was therefore interested to compare my algorithm with the authors’. My approach was to start with a conventional actuarial formula containing two unknowns, the rate and the term of the Temporary Decreasing Assurance. It was then a simple matter to set up a loop to calculate and test the rate for terms of 1, 2, . . . years until the correct one was found. This should be quicker than the loop within a loop suggested in the paper. Another little criticism of this algorithm is that the computer is asked to calculate v ½in every inner loop, even though the authors point out in Section 2.4 that exponentiation is slow. It should have been calculated once at the same time as v. We all know that computers are very fast machines, and so what does it matter if we don’t write programs efficiently? I think we should bear in mind that writing in a high-level language is in itself inefficient, because time is taken to compile it and the compiler will not produce such an efficient program as a human programmer would because each instruction is compiled into a little routine, and there will be much wasted time and space. If a program to output the results of some calculations on a line printer is written in a low-level language, it is virtually certain that it will be peri- pheral-limited, i.e. the printer can be used at top speed and still the central processor will not be fully occupied. With a complex program written in a high-level language, the processing can sometimes be so slow that the line printer cannot run at top speed, and if time-sharing or multi- programming is in operation, this can be very inefficient. This leads me on to my main criticism of the ideas in the paper, which is that I am not at all happy about the system of packages which, if I understand the authors correctly, is suggested should be used for actuarial programs. In a big program efficiency is important. When I was testing my valuation system, I found to my horror that I was taking up to 2½hours to read a magnetic tape, whereas low-level programmers never took longer than 20 minutes. After sifting through for inefficiencies I was able to improve the time to about 55 minutes per tape. I have been a little amused by the fact that working with a computer seems to breed more respect than being an actuary. As usual familiarity 190 Actuarial Programming Methods breeds contempt. A colleague said to me the morning after a recent American space flight “With your experience of Computers would you trust your life to a computer and go in a rocket to the moon?”. One can but hope that the computers and programmers at Cape Kennedy are more reliable than those in the average Life Office.

Mr. J. D. U. Harsant.—It gives me great pleasure to attend a meeting of the Faculty and to avail myself of the privilege which the Faculty gives to members of the Institute of speaking at its meeting. The paper presented this evening is of great interest to me as we have in my firm used both Algol and FORTRAN for some time. The circumstances of my firm differ in some respects from those implied by the authors in their introduction. We are in full-time consulting practice and, therefore, our problems are different from those of life offices against whose background the paper is written. Before going further I would like to emphasize some of the points made by the authors in their introduction as I feel these highlight particular features of the high-level languages which make them so suitable for my own work. If I may quote from the last sentence of Section 1.3: “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”. In my firm we are faced with having a wide variety of work, much of which falls into a few distinct categories, but where one particular job will differ in detail from another. There is much to be gained from running this type of work on a computer, but in order to do so the procedure for placing the work on the computer must be flexible. Before starting, our first problem was to decide whether it was easier for our staff to instruct programmers skilled in writing computer programs or to teach our staff to program for themselves. Our investigations led us to an understanding of high-level languages, which is in accord with the quotation I have just made from the paper and we, therefore, concluded that our actuarial staff, many of whom are mathematics graduates, would have to learn to program. In the initial stages we were freely given facilities at Liverpool University on their computer, a KDF9. At the time we started, this machine was only capable of compiling Algol, and so our first work was done in this language. As our experience grew, we found that Algol was not as suitable as FORT- RAN for running programs related to pension fund valuations, and we therefore moved over to this other language for that purpose. At the same time we used the Manufacturers’ Bureau in conjunction with the University as we found we had greater facilities. There, for example, we were able to read the data on to magnetic tape off line, thus saving the cost of using the full facilities of a large computer during the time taken to read the cards. We now find that the majority of our arithmetical work is carried out by computer, and great advantage is derived when calculating the premium rates for life offices through having these presented by the computer in a form which is suitable for immediate presentation to the type setters. As far as pension fund valuations are concerned, our standard programs have to be amended to take account of detailed differences from one scheme to another, and in doing this a language such as FORTRAN, which is Actuarial Programming Methods 191 written in such a way as to be prepared on punched cards, is easier to handle than Algol, which, generally speaking, is prepared on paper tape. All in all, it is my feeling that if we were starting again we would restrict ourselves solely to FORTRAN and not use Algol at all. For this reason I am rather sad to find Algol in the examination syllabus, when our staff, by and large, have to use FORTRAN in their daily work; use FORTRAN I might add on the basis of their own recommendation rather than by any preconceived views of the partners. Turning now to slighly more technical matters, I would like to emphasize the need for good documentation of programs, particularly as this is one of the aspects of programming which is so easily neglected and yet is so vital to the continuation of a satisfactory system. To conclude, I would say that I am most grateful to the authors for having written their paper, as this is a subject about which we all should know more and we should certainly derive benefit from it.

Mr. A. G. Mills.—During the discussion that followed the presentation of Sidney Benjamin’s paper “Putting Computers on to Actuarial Work” to the Institute of Actuaries in 1966, Mr. G. A. Brown felt that there was nothing incompatible in an actuarial student spending a year or two of his studenthood working in the computer department. At that time he felt he was in the minority in putting forward this suggestion. I do not know what the general feeling is of members here this evening but I certainly agree with Mr. Brown. Having spent three years on pensions work I was asked if I would like a move to mechanization department as a programmer. This rather surprised me as I had not anticipated this as a possible development in my career. However, today, after having two years experience as a programmer followed by a further eighteen months of systems administration I do not regret having taken advantage of the opportunity. I feel that such an experience would be invaluable to any actuary considering using Algol or any other type of programming autocode. One can make much more efficient use of an autocode knowing something of how the compiler works—one learns to avoid time-consuming instructions, however elegant they may appear. In Section 3.2 the authors state that the user of Algol may not have to worry about how the computer performs certain routine calculations such as sqrt(x). However, I maintain that with such a knowledge, albeit brief perhaps, he will nevertheless produce better programs. One must beware of thinking that given an autocode such as Algol then after brief instruction anyone can produce efficient programs. This can lead to very inefficient programs in fact,. especially so if prepared packages are used. Such packages can be very useful in certain circumstances but the user must beware. During the last few years a large number of Algol compilers have been completed both in Europe and U.S.A. Unfortunately there are rather few compilers accepting the full Algol 60. This means that for each computer there are special rules regarding not only code procedures and &put-output, but also deviations from the official Algol 60. For this reason it is highly advisable that before an Algol program is written one gets acquainted with the Algol conventions for the particular computer on which the program is to be run. Bearing all this in mind there is a great advantage in having package routines, namely when a relatively small and simple job is required rather quickly. Input-output routines for use with standard files are typical examples. The development of vast and powerful machines means an 192 Actuarial Programming Methods enormous amount of work can be done for relatively little cost but it is still necessary to go quickly from the initial stage of deciding the work to be done to the final stage where the result rolls off the machine. This brings in the human aspect. A man sits in his office, sets up what he wants done, and works out the format and the calculations he wants done. He then has to either program it himself or give it to a skilled programmer. Either way this could lead to a considerable amount of delay which would be unfortunate as it created a blockage and it would be a day or two before the result was obtained from a very fast machine. This is where autocodes and packages would be very useful. In Section 1.7 the authors look forward to the time when sufficient work may have accumulated for someone to select the recognized standard methods and produce a text-book of actuarial programming. In a wider field, already more than 300 algorithms of different kinds and of different quality have been published. Work is in progress on a handbook for numerical computations of all kinds : solutions of equations, approximation, differential equations, special functions, matrices and so on. The handbook will consist of at least five volumes and it is worked out by prominent specialists on numerical analysis from Europe and U.S.A. It will contain a collection of algorithms, all described in Algol. The algorithms will be carefully checked, and further they will be accompanied by explaining text regarding the scope of application, precision, speed, and other details which will be of interest when they are used in a computer program. The authors have outlined a considerable number of routines but I was rather surprised that they had included no examples of simulations. Unlike an earlier speaker I feel that in times of intense competition when on-the-spot, but informed, decisions are vital, simulation methods must play an increasing part in business life. There are perhaps four require- ments that simulation programs will need. These are : 1. The ability to generate random numbers to conform with the more usual distributions, i.e. Normal, Poisson, Exponential, Rectangular, etc. 2. The facility to input histograms against which random numbers can be generated. 3. The facility to output results in histogram form, or within stipulated class intervals. 4. An automatic time advance routine which “ scans ” the state of the model, advances time and adjusts the model accordingly. A programmer could write the necessary routines in Algol but it is convenient to have them readily available. Finally, mention is made in the paper that the program itself in Algol is the solution to the problem-not just instructions to a computer to calculate the solution. Are we tending to the situation where the written and possibly the spoken word in everyday language and the computer program are the same ? Already we have optical readers that will scan handwriting and by testing numerous possible shapes against what is actually written will decide which letter of the alphabet the character is most likely to represent. One’s imagination does not have to be stretched too far to see the day when the spoken word will be analysed in a similar manner by a computer.

Mr. E. J. W. Dyson.— I am a member of the Institute and am very glad to take the opportunity of speaking in this hall. I should like to begin by joining with other speakers in congratulating the authors on their Actuarial Programming Methods 193 paper, which will be of great value to students and others. In Section 1.5 the authors refer to the Institute’s new Intermediate (1) examination in Numerical analysis; I should like to point out that nearer home, in the Joint Preliminary Examination, candidates may be asked to construct a flow chart, or to give details of a program of calculation. In Section 1.6 the authors say that Algol is useful for expressing solutions even if a computer is not to be used for the actual calculation; I agree with this, and disagree with Mr. Limb when he says that the standard mathematical or actuarial notation is sufficient. It should be, but in practice it is not always so; for example when summing an infinite series, a routine in standard notation will not always ensure that the series converges; in the form of an Algol procedure this point is much less likely to be overlooked. I was sorry to see that no mention was made of simulation; this can be particularly useful when a stochastic element is involved; it can also be useful in the solution of complicated reversionary interest problems; for example I can quote a case in which a relative of mine was concerned where there were four life tenants, with widely differing incomes and free estates, all very much the same age, with cross remainders. The expecta- tion of the ultimate reversioner would be very difficult to compute with any accuracy, but it would be simple to simulate the situation a number of times to estimate the solution. I was also sorry to see no mention made of the numerical solution of differential equations; from one point of view approximate integration can be regarded as the numerical solution of a differential equation of a special type, with one variable missing. Finally, I should like to say how glad I would have been if the paper had appeared a year earlier; the problem of finding suitable reading for Intermediate subject 1 of the Institute’s examinations could have been greatly eased.

Mr. I. M. Aitken.—The paper is devoted to Algol and how it can be utilized to solve actuarial problems in a very neat and concise manner. At the same time the authors are conscious of the disadvantages of this language; namely its poor character handling and file processing facilities. They state that one of the purposes of the papers is to show the non- computer-orientated actuary that programming is easily assimilated by those who do not have any encounters with the machine. At the same time they hope to encourage the publication of actuarial programming solutions. Nowadays most life offices have their own computer and at this point. it is prudent to state the purposes for which an office is most likely to use it. I believe that it is for speed, accuracy and manipulation of routine work, for example:— Valuation of liabilities. Debiting and crediting premiums. Premium renewal and arrear notices. Annuity notices and cheques. Commission statements and cheques. Pension castings. Actuarial work, such as S.Vs. and P.U.Ps. Valuation of assets. In all of these fields there is no doubt that the computer is a valuable asset to the life office and it has freed clerks from mundane and routine 194 Actuarial Programming Methods work. The machine is able to process repetitive data very quickly and at the same time guarantee that the output is free from error. Now for this type of work the computer language necessitates good character handling and file processing facilitites either in a high-level or assembler language. I wonder why the authors have introduced Algol to the Faculty rather than COBOL, PL/I or RPG which can be used for this very purpose. Not for one minute do I dispute that Algol is a very elegant and easily written language for mathematical work and outpaces the other languages with its mathematical manipulation but I wonder how often the life office actuary will want to go to the lengths that the authors have gone with exponential and polynomial functions. From experience I found that the languages with good data handling facilities are sufficient for the life office work that is available to the computer. At the same time they have the advantage of being able to handle a lot of data reasonably quickly. Up to now I have never experienced any great difficulty in calculating annuity, assurance or increasing assurance factors at a particular rate of interest using one of the non-mathematical languages. At this stage I feel that there is a lot of more fundamental education required of the non-computer-orientated actuary. For example, asking him to explain concisely and accurately everything that he would like done on the computer; this is of even greater importance if the programmer does not have an actuarial background. An actuary is likely to ask a programmer to write a program for some special purpose. He will explain what he wants done to 99% of the data which is to be processed. Unfortunately it is this other 1% that causes more trouble than the routine cases. He has to be taught to think about this 1% at the programming stage and not when the program has been run and the answer is obviously wrong. For instance, how that very unusual reassurance policy is to be treated or what has to be done with this special mortgage protection policy which has unique conditions of assurance. In the past the actuary would cross the bridge when the clerk appeared at his door and said, “I came across this unusual case which does not fit into the pattern—what shall I do ?” The other field of error is that the actuary will explain what he wants done but not in the sequence in which it is to be executed and naturally this can play havoc with computations. Now with the faciltities of a computer the actuary will explain what is to be done if an unusual case arises and in what order computations are to be carried out. For this, I believe that the best approach is to ask the actuary to draw a flow chart, of all his computations writing “start” at the beginning and finishing with “end”. Between these two points he should explain all his calculations in the order that they are to be carried out and what is to be done if his conditions are not met. If any element of programming is to be introduced into the Faculty examinations, I would advocate that it is in the form of flow charts which utilize loops and branches. This will train the student to adopt a logical sequence to his work and at the same time will not tie him down to a particular language which may not be used by his own office.

Mr. S. Benjamin, in a written contribution read at the meeting, said :— There can be no doubt that this is a paper of the very highest excellence, and it covers a tremendous amount of ground very quickly. In fact there Actuarial Programming Methods 195 is hardly a single part of the Faculty’s or of the Institute’s examinations for which this paper could not be suitable additional reading. There are a few miscellaneous comments I would like to make within the self-imposed limits of the paper and a few outside those limits. I do not see how the authors could have done otherwise, but it would be interesting to know whether anyone who did not know programming before he opened the paper could pick up enough Algol to follow the paper from the brief introduction given. One of the books cited by the authors, Numerical Methods in Algol by J. Hawgood was on a short list for the Institute’s new syllabus but I personally thought the Algol introduction in the first part was too concentrated for the book to be self- contained. I would have expected a programmer who might have been ignorant of Algol to have found sufficient explanation in the paper to continue, but it would be interesting to find out. It might have been helpful to explain that the semi-colon plays the important part of showing the end of a statement and that spaces and new lines are irrelevant except for neatness to the eye. When it comes to numerical analysis on a computer it is often the simpler method which serves better. As an example in Section 5.4 the authors suggest the Newton-Raphson formula for finding the inherent rate of interest from the usual polynomial in a problem in compound interest. A simpler method of finding the root of a function consists of straddling the root with two values x0 and x1 say, and then successively halving the interval using at each iteration the half which can be seen to contain the required root because the given function has opposite signs at the two end-points. The first time I had to solve a typical compound interest polynomial the problem arose from a large fund with relatively small amounts of money entering monthly over 24 months. In the notation of the authors A, and A, were large. Thus the first derivative and the second derivative of the expression were also large and the Newton-Raphson method did not converge very fast. The method of successive bisection was considerably faster. Incidentally there were some negative yields involved in the data, which were extensive, and I now take the precaution of using 0 and 2 as opening approximations to 1 + i with an initial test thrown in for good luck. In the bisection method this requires only one more iteration than opening values of 1 and 2, i.e. = 0% and 100%. The whole subject of compound interest can now be covered by two or three Algol procedures and probably most of the examination syllabus could be discarded. One major use of Algol is that of communicating between human beings. It is noticeable that practically all of the algorithms in the collected set of algorithms published by the Communications of the ACM (Association for Computing Machinery) are written in Algol even though FORTRAN is also allowed; this is also true of algorithms published in the British Computer Journal. It is worth drawing attention to the algorithms of the ACM which now form an extensive set with international fame and application. The algorithms are issued in loose-leaf form and updated regularly by means of an elegant page numbering system. As the authors mention in Section 4.2 there are standard procedures which ought to be in any good statistical library. As actuaries become increasingly involved in non-life actuarial work I believe statistical procedures will come into greater demand. In the last part of their paper the authors rightly turn to actuarial programming notation and languages, a subject which was brought under 196 Actuarial Programming Methods scrutiny by being included in the last International Congress. Both Kunz, the author of AKTUARIAT, and I agreed in discussion at that Congress that the quick specification of jobs had been uppermost in our minds. Most of the work of an actuarial department is best thought of as a series of “one-off” jobs. Efficient regular running of the job afterwards is rarely an economic consideration. What is required is that the specification of the problem should itself be the program. One road to this objective is through the use of standard actuarial notation in programming. I avoided this approach and the one adopted in AKTUARIAT for two reasons. Firstly with limited effort available I wanted to avoid the use of any instruction format which lay outside an existing language, otherwise I would be landed with developing all the input format checking for- malities and logical error testing facilities required inside any reasonable compiler. Secondly I wanted a system which would still be useful even if it were not comprehensive, i.e. it was important to allow the user to revert to a standard programming language when he wanted to step beyond the facilities supplied. Incidentally at this point I would like to correct a minor error of description. In Section 9.2 the authors imply that the procedure set (col no) allows a column to be input only if first age and last age have already been set in the program, whereas the main point of the routine which inputs a column this way is that it does not know beforehand what the first and last ages are. The system is designed to allow programs to be written without knowing the first and last ages and without continually referring to them if they remain unchanged. As another example of a language which makes convenient and conventional assumptions during a program unless otherwise specified I would draw attention to ICL’s special purpose valuation programming language RIVAL. Amongst other neat features the user is allowed to make a list of bases and to refer to them in his formulae. Thus M2(X) means the standard commutation function M for age x on basis 2 as previously specified by the user. Stepping outside the paper for a moment it is worth noting that once ease of specification becomes more important than computing time then the statement of problems in “emerging cost” form is simpler. Thus in principle a pension fund costing is merely the procedure pay (x, rules) where the parameter x is the age and the procedure rules is, very conveniently, the rules of the fund. The expected decrement, in each future year can be found by a standard emerging cost programme and the value emerging in each year can be found by a rules procedure. In principle only this latter part need be specified separately for each job. Stepping even further away from standard methods we can use the procedure kill (x, l, y) where x is the age, l is the life-table to be used, and y is the resulting age at death found by random selection on the given life-table. This is the method used in my own office to solve complicated reversions problems where the rules of the trust cannot be expressed by standard actuarial functions. The main part of the program applies the procedure kill to each person involved and the programmer is required to provide a subroutine of the rules of the trust. A large number of simulations provides mean values and standard deviations as estimates of errors. This method is similar to the emerging cost method but replaces the projection by simulation. This is a most excellent paper which was a pleasure to read and its appear- ance at this stage of actuarial use of computers is most appropriately timed. Actuarial Programming Methods 197

Mr. W. M. Morrison.—I should imagine that angels would fear to tread in the footsteps of Mr. Sidney Benjamin. I should like to answer two of the questions posed by the authors. In both cases my answer is “No”. The questions are :— (1) Should the international actuarial notation be changed to fit programming languages? (2) Should the Faculty examination syllabus include programming methods? As to the notation, I use the present notation much more often for problems which are not for solution by computer than for problems which are—and I am sure most life office actuaries do likewise. I find the present notation much more readily understandable than any of the alternatives which have been suggested so far. As to the examinations, these languages are likely to be replaced by others as time goes on. These languages are easily learnt by those who wish to use them. Although Mr. Gwilt says he forgets where to put commas and full stops, some of us are quite capable of punctuating correctly in other languages. The present paper is a perfectly adequate introduction for the general actuarial student. I am against taking either of these questions any further.

Mr. R. Anderson.—During the past year I have had some considerable contact with a second generation computer, but unfortunately have no experience of high-level programming languages since no suitable software exists. Programming has on the whole been done using a low-level programming language assembler. Although this has in many respects considerable advantages over direct machine language programming, these advantages are obtained only at the cost of a considerable loss of efficiency. The efficiency with which a program operates is of material importance only if it is to be used regularly or if it has a lengthy running time. On the whole it is essential that programs forming part of the normal bread and butter work have a high standard of efficiency. The use of a high-level programming language for such work as production of renewal notices, premium collection, calculation of surrender values, etc., may well save programming labour and enable the program to come into use earlier, but this saving must be balanced against loss of efficiency which may, as other speakers have pointed out, be very considerable. Spare computer time is very quickly used up if one has to do a lot of rerunning because of either computer or program failure, and in spite of assurances received from manufacturers, computers do break down, sometimes for days on end. For the ordinary day-to-day work which needs highly detailed long term planning normal programming methods are quite satisfactory. The choice between a low-level or high-level language must be largely dependent on results obtained in practice. The circumstances are entirely different from those applying to the miscellaneous queries which the authors are discussing in their paper tonight. Here the running time of the job will not generally be material and normal progamming methods lead usually to a most inefficient use of the computer. Programs take far too long to write, to test and to “debug” so that overall the job can often be quicker done by hand. The inefficiency arises because of language barriers. The actuary is unable to express his request in a form which the programmer can easily 198 Actuarial Programming Methods understand and the programmer’s use of the computer’s language is not good enough to obtain the results at a first attempt. A great deal of time must be spent in changing the specification into a form ready for the programmer and in vetting the completed program. Actuarial mathematics is complicated and there is little point in trying to get a programmer to understand it. Surely it would be far better to bridge the gaps in one step so that the actuary can present his request directly to the computer. Perhaps he will not dot all the i’s or cross all the t’s the first time, but sooner or later he will, and he will then find the computer as useful and efficient a tool as it already is to the scientist or engineer. The authors of tonight’s paper have shown us how easily and quickly this object can be achieved with the use of Algol. I have to thank them for the clear and simple way in which they have explained the logic of the language, and I sincerely hope that the subject will not end here, but at least should proceed until a library of routines has been established. I feel that tonight’s paper has excited my curiosity and I look forward to the time when a suitable computer is at hand and I can try the method for myself.

Mr. E. C. Morrison, closing the discussion, said :—Tonight’s meeting is really another chapter in the book last opened before the Faculty some two years ago by Messrs. Lundie and Wilkie. We must be grateful that Mr. Wilkie has himself taken up the challenge to further research on computer methods implied on that other occasion, and I am sure he is fortunate in having Mr. Robertson as his co-author. The paper before us is the outcome of a great deal of joint effort. Our authors have set out to acquaint us with a higher level language suitable for actuarial work and in my opinion they have righly chosen Algol for this purpose. But this approach tends to divert attention from a quite fundamental difficulty—Mr. Robertson has made it clear that they do not advocate that Algol should be adopted as a standard language: they have taken Algol as an example of a higher-level language and shown that it does have considerable power in the actuarial field. I feel that we must take the problem a little farther and see what sort of case can be made out for the adoption of Algol as standard. It will be appreciated that I do not believe there is currently any better language available on which we could standardize. How then does Algol rate, considered as an actuarial standard language? Its syntax and semantics were specified and developed by a group, primarily of mathematicians, with the aim of producing a language independent of any particular computer, and suitable for their work. It has met with fairly wide acceptance on this basis, particularly I think outside the United States. We must try to assess it for our purposes on two counts, first its value as a means of expressing and working with actuarial problems on paper, and second its value as a link towards producing numerical results via an actual computer installation. On the first question, our authors have shown how to express the solution of several actuarial problems in the language, and have clearly demonstrated that in their sympathetic and skilled hands most elegant solutions can be found—and I understand that they have no great experience of the use of this particular language. The little problem of the leap year which is so clumsy to express in English is dealt with virtually in one line of Algol. But it is in the more complex problems such as those involving columns and arrays, that the language really comes into its own, Actuarial Programming Methods 199 and in the middle sections of the paper there are several examples that amply demonstrate its power. I would like, however, to stress the point that it is no use setting out to write a solution to a problem in Algol before one is very very clear as to the expression of the solution, however clumsy, in a traditional form. It may be that a numerical answer cannot be derived from the traditional form, and that a translation into Algol is necessary in order that the calculation facilities of the computer can be utilized. But this use of Algol does not require a deeper insight into the problem than does the perhaps clumsier analytical work that has gone before. I would take the view that it is not necessary for the actuary to be able to express the solution of a problem in a programming language, it is sufficient to be able to reach the stage of saying, for example, “Here we have an iterative formula which an appropriate language and computer can deal with”. The problem is in having a sufficient knowledge of mathematics to be able to visualize a solution that can be described to a programmer who will then be able to carry the work forward to a final numeric answer. On the second point, an Algol solution to a problem is complete in the practical sense only when the computer delivers an answer, possibly in sterling, possibly the ordinates of a curve, and so on. Here I come to a real difficulty of my own. In my office we have available the facilities of a second generation computer of reasonable power for data processing purposes but with minimal facilities for arithmetic. To mention a trivial matter, every morning in effect we have to give it a little card to memorize for ordinary arithmetic additions, so that it can go along the top to find “three”, say, and then down the side to find “five”, and it then knows that to find the result of addition it must go to the intersection where, lo and behold. it finds “eight”. You will not be surprised to learn that this computer has no pretensions to understand Algol. But, far more interesting and disturbing, we are currently investigating a third generation successor to it, a sophisticated and powerful machine on which one could easily spend £½m. and here again there is no implementation of Algol. So we must not assume too readily that Algol will be available wherever there is a medium sized computer. It is of the very greatest importance to a management properly concerned with expenses to foster the standardization of computer languages. The cost of reprogramming, or some substitute, to enable switching from one computer to another—even from the same manufacturer—is one of the more distressing features of computer development. It may be argued that future development could be directed towards using one’s own computer for data processing where input and output are important; but additionally, one may be able to justify having perhaps a typewriter terminal giving access to a remote giant for one’s mathematical problems, as Mr. Gwilt suggested; and the obvious thing would be completely standard programs, universally available, on this central processor. Now if we accept that there is no better language for our problems than Algol at present, and if the meeting accepts that the practical disadvantages of Algol are real, then the farthest we can go is to say that higher level languages are a good thing and that we are grateful to our authors for establishing this; but that we cannot see our way to standardizing on Algol, at least for the present. Turning to another matter discussed in the paper, I find that I cannot go very far with our authors in the suggestion that Algol might be wrapped into the examination syllabus. It would seem a dubious matter for us to 200 Actuarial Programming Methods require that students studying compound interest, for example, should be able to trot out their answers in fluent Algol. I would feel that the only place for examining in Algol would be in the pure mathematics of Part I, that is, if we were prepared to contemplate such a step at all. Let us bear in mind what purposes ought to be served by our system of examinations. The present trend of mathematical studies at univer- sities would seem to indicate that quite a proportion of graduates will have a background of Algol, and will find it easy to link this skill to actuarial matters. On the other hand I would hope that the school leaver will not have been exposed Algol, for this would seem to demand yet another specialization at the expense of a good general education. It is certainly intriguing to find the seven year old coming home to announce that two plus two equals one, one, if—in his words—you are bundling in threes; and the eleven year old working with problems in binary. Perhaps we have the matter dealt with adequately at the moment, when, as Mr. Dyson pointed out, there is provision for optional questions on programs of calculation in the Joint Preliminary Examination. Are we not then assured of a considerable number of entrants to the profession who will have the necessary background to keep the rest up to date, and that it is not necessary to demand the attainment from all. Further, I am of the opinion that a student should not be placed in a computer department until Part II has been safely left behind. This conflicts with my suggestion that Algol should be examined, if at all, only in conjunction with the pure mathematics of Part I and so I feel that the balance would lie with the exclusion of particular programming languages from the examination syllabus. However I would like to think that every entrant to the profession was able to draw a good flow chart—flow charting can refer equally to mathematical routines or data processing and is quite independent of computer or computer language. Flow charts are unfortunately a printer’s nightmare—and this leads me straight to the matter of actuarial notation. There are reasons why our system has held its position over the years. Perhaps most important, the heaviest users of the notation are our students and their tutors and examiners; and the existing festooned symbols are compact, easily recognized and generally adequate for student purposes. I doubt whether the significance of a list within brackets can be taken into the mind nearly so readily. In day-to-day work there is little call to express ideas in actuarial symbols; it is generally sufficient to know that a number, placed in a certain position on a calculation sheet, always represents the value of a certain symbol. The basic problem is a printing and editing problem, and I think we should be prepared to live with this in the same way as we are bound to live with the printing problems typified by the ordinary algebraic expressions of Section 3.5.5. This has not been an easy paper for the Faculty to discuss, for we have been asked to visualize a whole computer language from a very few paragraphs of description, when the average manual on the subject runs to a hundred pages and there is a considerable literature beyond that. I feel our authors are to be congratulated on the amount that they have succeeded in conveying within small compass.

Mr. A. D. Wilkie, replying to the discussion, said :—I am very pleased to find that I agree with almost all of the things that have been said in the discussion this evening. I must at once make it clear, however, that Actuarial Programming Methods 201 although both Mr. Robertson and I are on the Board of Examiners, our views are entirely our own, and have not been discussed with other members of the Board at any stage. Much has been said about the efficiency of the computer object program -or rather its relative inefficiency with higher-level languages. Now, while it may be desirable to minimize the run time for very frequently run programs like the control monitors on a daily updating system, it is necessary to take into account the overall time and cost required to produce results from the start of programming to the final output. The example of an actual program in our paper took only a few seconds to run on an ICL 1904 including compilation and execution. This is quite trivial compared with the ease of programming it in Algol rather than in an assembler language. Mr. Aitken asked why we used Algol rather than some other language. I am familiar with COBOL, but it is not very elegant mathematically, and it is terribly wordy in its style, with a lengthy data division and a lack of mathematical expressions. RPG is a different type of language altogether, allowing one to reproduce the plug-board of a punched card machine on a computer, and of no use for our purposes. FORTRAN is widely used, as we have heard ; I think Algol is more fluent and elegant, but it is not difficult to translate from one language into the other where necessary. The lengthy procedure cheb in Section 7.6 was in fact copied from a FORTRAN sub-routine in under an hour. PL/I is a language which neither of us was familiar with when we started this paper. Had we known more about it we might well have used it in preference to Algol. I have the impression that many Algol features would translate into PL/I with very little change at all. Mr. Gwilt, mentioned the use of terminals for conversation between the actuary and the computer. I have seen in operation a simple system whereby one typed in a bit of program, then got the computer to execute it and to show the results so far. It would be quite a challenge to develop a suitable actuarial program for this purpose, but it would allow the actuary to experiment with a really powerful calculator at his elbow. Simulation methods have been mentioned by several speakers. We left these out for two reasons. Sidney Benjamin’s paper in J. I. A., vol. 92, p. 134 covers them very well ; and we have no experience ourselves to enable us to add to what he has already said. Mr. Limb mentioned curve-fitting and referred to Lloyd’s paper in J.I.A.S.S. Lloyd’s method, unlike a least-squares method, does not converge to a unique answer. Several different answers would be equally acceptable. Where the least-squares method disagrees in its criteria with the conventional actuarial criteria, my opinion is simply that the conventional actuarial ones are wrong. So I stick by our least-squares method. Mr. Thomas pointed out our inconsistency in including v ½ in every inner loop of an algorithm. This was done simply for clarity; of course in practice one would write w: = v 0·5 at an early stage and use w instead of v 0·5 thereafter. The proposed new notation has been discussed, and by some at least rejected. All I can say now is that in one Section, 8.2, where old and new symbols appear side by side, there were far more printing errors in the first proof in the old expressions than in the new. The Editor will support us on this. And, as for unfamiliarity, of course the new symbols are less familar than the old, but this is because we have all used the old ones for P 202 Actuarial Programming Methods so long, and have seen the new ones only briefly. They would be just as easy to learn in the first place. I have had the impression that a number of sneakers feel that actuaries do not need to learn anything very much about computers. On the contrary. I think that it will be as essential in the future for an actuary to understand an elementary program of the sort we have described as it is at present for him to be able to use a slide rule. May I finally say thank you, on behalf of Mr. Robertson as well as myself, for such a lively, stimulating, and on the whole, encouraging discussion.