- Email: [email protected]
EEL: A System for Specifying and Evaluating Econometric Models
Copyri ght © I FAC Dyna mic Modellin g a nd Control of Nation al Eco nomies. Edinburgh. U K . 1989
EEL: A SYSTEM FOR SPECIFYING AND EVALUATING ECONOMETRIC MODELS R. G. Becker Dl'p(///II/PI//
oI
Elec/riml E lIgilletrillg. Imperial Colhge, LOlldoll Svrl/ 2BT, L'/\
AbstTact. A project to produce an econometric software system is described in broad detail. The software system wlll eventually comprise a model description language. a translator for the language into an interpreter machine code. interpreters and finally simulation. optimisation and estimation packages. At present the language, translator and interpreters are working and have been tested. Work is proceeding on the simulation and optimisation parts of the system.
INTRODUCTION quarterly model un_real; Ithis is the model header !declare a variable for which there is no data genera te my _trend; !this declares a coefficient coefficient param- 1 2 3 4; Ihere's how to get a time trend and illustrates a date my_ trend - 100*(time-1980:1); fan autoregression !unemp +unemp.l +2unemp.2 +3unemp.3 .. .-0.25xlog(pay) ar(param)unemp - 0.25*1" pay; 'a conditional equation limits unemp to two million if(unemp>2e6) unemp - 2e6; !declare tax exogenous prices and pay endogenous exogenous tax; endogenous pay prices; la wage price spiral pay is a moving average of prices pay - ma(O.1 0.2 0.3)prices; prices - l.l*pay.l; Ifirst lag of pay is written pay .l 'now an un-normalised equation Ithe bal : at the beginning says what we solve it for bal: exports - imports - bal - 0; !we can use other brackets and lag expressions exports/prices - (O.2*diff loglO(pay/prices») .2 ;
Work is being carried out by members of the PROPE group at Imperial College to produce software to assist economists to specify. simulate and perform more complicated computations with econometric models. The work is as yet unfinished. but the broad outlines are as follows:- firstly. we have developed a simple language for specifYing discrete time sets of equations which is called EEL (Econometric Equation Language). Secondly we have written a translator for the language (the program is called EEL) which maps the human oriented EEL language into machine code for a simple stack machine. The actual output of the translator contains a lood deal more than just the code for the equations of course; in fact the machine code file contains sufficient information to allow a second program, LEE(EEL backwards) to reverse the translation process and (modulo white space) produce the original input. The third component of the work involves a pair of interpreters for the stack machine code to allow both evaluation of the equations and when required analytic differentiation of the model. The final part of the project is the incorporation of the interpretation system into a program for simulating and optimising econometric models.
Fia. 1 A Sample of the EEL Language
THE EEL LANGUAGE The language (Lee 1988) which we have developed to specify models is extremely simple and should be learnable in less than an hour; we use a fairly standard character set and simple conventions. A model consists of a header which specifies the name and periodicity (ie the type of timing annual quarterly etc.) of the model; this is then followed by an arbitrary number of declarations and equations. The header and each declaration and equation are terminated by a semicolon. Comments which begin with the character ',. and continue to the end of the line may be inserted anywhere reasonable (Le. not in the middle of some other object like an identifier) . There are some reserved words to allow standard functions to be given names (e.g . 'In' for natural logarithm and 'ma' for moving average etc.) and to allow meaningful declarations. Equations do not have to be normalised and in most cases the EEL translator can figure out which variable is to be solved for in a specific equation. in more complicated cases a simple notation makes this clearer. To illustrate all this figure 1 shows a simple model without any economic meaning.
for i-1 •••• .,n and t-1 •••• .,T. In eqn. 1 Y. E Jl"+tn is a vector of variables at time. t. 9 E Jlo is a vector of time invariant coefficients. ~ represents the maximum lag in variables required and f. g E Rn are possibly time varying functions representing the left and right hand sides of the n equations. The whole raison d'etre of EEL is to get away from the rather abstract formulation in eqn. 1 and represent equations as the econometrician would write them in his papers . Thus instead of using vector notation. variables are referred to using mnemonic identifiers. A model written in EEL consists of comments and statements. comments can begin anywhere in a line and start with the character .,' (exclamation mark) and continue to the end of the line. EEL statements consist of identifiers. constants. operators and some special delimiters. Every EEL statement is terminated by a semicolon (';') character. Comments which occur immediately before and during any EEL statement may be kept in the translator output file and are assumed to be associated with the statement; these comments may be accessed later for use as memory aids etc.
Basic La1l&Uale Elements The EEL language is designed to represent discrete time nonlinear dynamical systems of equations like eqn. 1
55 1
R. G. Bee ke r
552
An EEL identifier is a sequence of characters that starts with an alphabetic letter which may be followed by an arbitrary number of letters, digits or underscores(,_') . The case of the letters is important ie the identifiers 'A3' and 'a3' are different! It would have been possible to use other characters in identifiers which are not required elsewhere in the language, but since £ is not a valid character and $ is, it was deemed better to restrict the language. Al Unemployment An_extremely _ long_ identifier _ is allowed_if _you_wish
periodicity _id discrete annual/yearly biannual triannual quarterly monthly weekly daily Fi".5
predeclares year year, year, year, year, year, year,
semester trimester quarter month week day
maximum subperiod NA NA 2 3 4 12 52 365
Periodicities and Predeclared Variables
be available for all required lags and simulation periods;
(2) endogenous variables are defined by the model Fig. 2 EXamples of EEL Identifiers Constants in EEL are at present all numeric; there are three kinds of constant, real, integer and date. The reals may be given in any reasonable way e.g. fixed point, scientific notation etc. Integer constants are used only to define lags and as the arguments to summation functions, however, reals are not required to contain a decimal point. Date constants consist of two integers separated (without any intervening white space) by a colon (':') character. The f irst integer represents the year and the second the appropriate subperiod. The range allowed for the sub-period depends on the model's periodiCity, the first sub-period is always 1 and in a quarterly model the last is 4 (it would be 12 in a monthly model). At present we cannot distinguish a date from a real in annual models; we also have no notation for dates B.C. although this is only a restriction for archaeological economists. Dates may be used anywhere that a real can and on the right hand of a special operator a which evaluates a variable at a specified date. 1.9 0.8
o
100 .7 0.0
1985 1985:1 1 2 3 etc. 123e-45 .0Ie+l00 0010 0.Oe+l0 lel0 1979:365 etc. etc.
Fig. 3 Examples of Constants The first statement of any EEL model is the model header statement which specifies the model periodicity and the name by which the model is known. periodicity _id
model
modeLid
Fig.4 The Model Header Statement Here per,od'c'ty_,d is the name of a particular periodicity (the allowed values are shown below in fig 5) this is followed by the keyword model and then the model identifier. The statement is terminated by the semicolon character at the end . The model header allows the EEL translator to understand date constants and also to predeclare some special variables. The variable, tlms, is always available and as might be expected it ticks along at a rate of once per period; this variable allows the "eneration of trends and can be used in comparisons with date constants e.". if(time<1988:3) etc. The other variables (if any) that are predeclared depend on the periodicity and are shown in fi"ure 5. In EEL variables correspond to time varyin" quantities with a name; coefficients on the other hand are time invariant. The identifiers for variables should correspond to the names attached to data for the correspondin" variables. Thus if you have data for unemployment which is called unemp then the appropriate name for the EEL model variable would be 'unemp'. Within an EEL model variables are divided into three classes, (I) exogenous variables are assumed to be defined externally, data for this class of variables must
equations and data must be available for all required lags; (3) generated variables are defined by model equations, but no data need be available, this means that generated variables should be finally determined by external data. In EEL the type of a variable can be specified by using a declaration of the ri"ht form although it may not be always necessary to declare a particular variable. exoaenous identifier identifier identifier ; endOBenous identifier identifier identifier; generate identifier identifier identifier; generated identifier identifier ..... identifier; coefficient identifier value; coefficient identifier - value .. .. value ; Fig. 6 Variable and Coefficient Declarations Coefficients are declared in a similar way, but each declaration also has to specify the value or values of the coefficient. Coefficients come in three types, (I) scalar rea Is, (2) sequences of reals for use in moving averages and auto-regressions etc. and finally (3) scalar inte"ers for use as arguments to summations, lag operators and the like. The reasons for having named coefficients are firstly as a mnemonic aid; specific coefficients may appear more than once in the model, "IVIng them a name forces them to be the same . Secondly, it may be necessary to refer to specific coefficients at model simulation time, for example to change some policy reed back parameter etc. However, it is intended that it will be possible to alter the value of any individual constant or constant sequence, that appears in the model, without retranslation . This will include altering the lengths of coefficient sequences in moving averages etc . There are restrictions on the use of identifiers for coefficient sequences; at present a sequence identifier may only appear as an argument of the moving average and autoregression operators. endOBenou8 unemp output gdp; exogenous tax_ rate VA T corporation_tax; coefficient c_gdp - 1.5; ! a scalar real coefficient a_unemp - 0.7 -3.1 prices@1980:1 sequence coefficient sum_ length - 5; , a scalar integer
'a
Fig. 7 Examples of Declarations The only other statements in the EEL language besides the header and declarations are equations and two simple statements which affect equations. Equations come in two forms conditional and unconditional . We have made the assumption that any particular equation is to be used to solve for one variable only; this is normally the case in econometric models. To be more specific, it is required that every equation is associated with either an endogenous or generated variable ( a further class of dummy variables may be introduced later), this allows the translator to unambiguously resolve "roups of cond itional equations. There may be more than one conditional equation associated with a non-exogenous variable, but there can be at most one unconditional
EEL: A System for Specifying and Evalua tin g Eco no metri c Mod els equation. Equation statements take the forms shown in figure 8 below. LHS - RHS; I unconditional identifier: LHS - RHS ;!unconditional for identifier if( condition) LHS - RHS; I conditional if( condition ) identifier : LHS RHS ;Iconditional equations; I following equations can be adjusted identities; I followinll equations cannot be adjusted Fill. 8 Equation Statements and their Modifiers Here LHS and RHS are expressions involving variables etc. It is assumed that the variable for which the equation is to be solved appears unlagged in the LHS expression. In the forms with IdentifIer : the identifier is that of the variable to be solved for ; this is to assist the translator in cases where the LHS expression contains more than one possible candidate for the explained variable. The EEL translator makes several assumptions to ease the modeller's task; a variable will be chosen automatically as the explanatory variable for a given equation using the following rules I)
2)
3)
4)
Candidate variables are those appearing unlagged in the left hand side which are not already known to be exogenous. If the equation is unconditional then remove from the list of candidates those already known to have an unconditional equation (since we don't allow multiple unconditional equations for the same variable). If ther e is only one candidate that must be the explained variable. Otherwise there is an error or the modeller should specify the explained variable using the IdentIfIer : form. Operator
Priority Meaning Associativity or, I boolean disjunction I left and, & 2 left boo lean conjunction na less than 3 < <3 na less than or equal >3 na greater than or equal greater than na 3 > equal to 3 na not equal to na <> 3 left addition 4 + 5 left subtraction left multiplication 6 * / 7 left division power 8 right **, unary plus 9 left + unary minus 9 left left natural logarithm In, log 9 10gl0 9 left base 10 logarithm exp 9 left unary exponential left power of 10 pwrlO 9 sqr left square 9 sqrt left square root 9 9 left absolute value abs min(. .. ) 10 na minimum of arguments max( •.. ) na 10 maximum of arguments left first difference 11 diff lag(j) i'th . lag left 11 diffk{i) left i'th . difference 11 left sum of i terms sum{i) 11 av(j) average of i terms left 11 ma(seq) moving average left 11 ar(seq) autoregression left 11 (, [, { expression group start 12 left ), I,) expression group end 13 left lag operator 14 na @ the at date operator IS na identifier 16 variable/coefficient name na constant 17 na constants Fig. 9 EEL Operators and Expreaion Elements
553
By default equations are assumed to have an error added to the RHS expression; the IdentItIes statement inhibits and the equatIons statement turns on this behaviour . At run time the equations can be adjusted and the identities cannot. We have assumed additive adjustments only as the error term will be correctly modified by the reduction to normal form if the equations are to be reduced. The EEL language allows the normal arithmetic operators for addition etc. and in conditions the relations less than etc. can be used; additionally several non standard notations provide for the evaluation of 10llarithms, movinll averalles etc. Figure 9 summarises the allowed expression operators. The priorities and associativities are chosen to reflect normal usage e .g. we can write a +b<-y/z in a condition and get the expected (a+b)s;(y/z). It is less usual to find the logarithm and exponential fUnctions as operators, however, this allows us to write I,.,(x) as In x and let rid of a pair of parentheses in a common case; since the unary operators associate we can also write exp In y (te y) or more usefully dlff In y to mean the first difference of I,.,(y). Another unusual feature is that we allow expression grouping with any of the pairs '0', '[J' and '()'; this is of benefit in our expected application since the expressions in econometric models can sometimes get rather lonll and the use of parentheses only becomes hard on the eye. The really non-standard features of the EEL language involve the differencing, lagging and averaging operators which are described in more detail below in figure 10 where we assume that I is either a positive integer constant or a positive integer valued coefficient identifier, seq is a constant sequence or a coefficient identifier(of length m, indexed 0 - m-I), n is a positive integer constant, £ is an expression and y is some general variable . It should be noted that our convention for autorellressions and moving averages differs from that which is commonly used; normally ar(s) means some autorellression of order 5, in our notation it means the operator [ I + s.LI (L being the lag operator). Similarly we can have operators such as ar(1.2 2.7) (meaning [1 + 1.2 .L + 2 .7 .L2) which are normally represented otherwise. y . n ( E ). n y @ date diff E diffk(i) E la E
Yt-n
ar(seq) E
Et +
gm
Yt-n Ydate
Et Et E t _.
Et -t E t _.
lagged variable lagged expression variable value at date differenced expression i'th. differenced expression i'th. lag of expression
m-I
L seq •. Et_•• ,autoregression
of expression
i-O ma(seq) E
sum(i) E
m-I
L seq•.E t _.
moving average
LE
sum of expression lags
i-O i-I
j-O av(i) E
I 7
1
t -J
i-I •
LE'-J
average of expression lags
j-O
Fil. 10 Non-standard Operators in EEL
Features of the EEL Langualle The EEL language was deSigned to achieve several main loals which include sufficiency, simplicity and ease of translation. The present version of EEL is probably not sufficient to represent all econometric models easily; there is no mechanism for representing expectations (or positive lags) or vector/matrix variables and operators. Similarly there are no conditional blocks (i.e. groups of equations delimited by If then else ete.>, this omission was deliberate . When model texts become large it
554
R. G. Becker
becomes all too easy to forget that part of an equation is in another part of the model merely because there was a convenient conditional block. When there are many switched equations with the same condition our notation will inevitably lead to some inefficiency. The notation used to indicate lags of variables and expressions (i.e. "object . lag") was chosen because it is textually short in that no parentheses are needed and since we don't cater for positive or variable lags no minus sign is required. The restriction of lags to constants is unlikely to cause many problems, there can't be very many cases in which the lag on a variable depends on the value of some other model variable. Another major deficiency is that there is no method of distinguishing estimated from imposed coefficients or that a particular coefficient/constant has a variance or other statistical properties attached to it. The present translator program is also unable to reduce arbitrary left hand sides, but will cope with most common cases. The need to associate each equation with a particular non-exogenous variable is due firstly to the fact that the most popular methods of econometric model solution c.f. Hughes Hallett (1984) or Fisher et al. (1984) demand reduced form equations and also to the ambiguity problem when conditional equations are allowed (see figure 11 below; the result depends on whether the conditional equation holds and which variable it is for). This in turn leads to the use of the colon to mean Is explained by (see fig. 8).
A-a. B-11
Operation of the Translator To translate a model from source into the form required by the simulation and other programs the program eel is invoked as follows eel (options] modBlfll_ (outputfllename] where the terms in brackets may be omitted. The modelfllename is the name of (or path to) the source containing the model text. The outputfllename is the name of (or path to) the file which is to receive the interpreter code; if this name is omitted then the name "out.mc" is assumed. The options control certain aspects of the translator's operation and are as follows -I
+1 -v
+vnum
- m
ire condition) A/B - "'f Fig. 11 Ambiguous System of Equations +m On the other hand the language itself is extremely simple and there are few restrictions, this makes it both easy to learn and use and also easy to translate. This means that it will speed up the process of change of conceptual model to final simulation.
-c
THE EEL TRANSLATOR -r
The translator program for EEL is written in the C language; the translator is called EEL and is up and working on IBM PC machines running MS/PC-DOS, on DEC VAX lIs running BSD Unix 4.2/4.3 and IBM's risc based RT 6150' running either BSD Unix 4.3 (which IBM calls AOS) or AIX, IBM's own version of UNIX. The translator is designed along fairly well known lines; the grammar for the EEL language was transcribed into the format required by the Y ACC compiler compiler (Johnson (1976» which was then translated using YACC into a table driven parser for EEL. Since speed of translation was considered crucial the lexical analyser for the translator was hand written using the approach recommended by Waite (1986). Translation of the equations proceeds in three main passes; in the first pass, which occurs as the input text is being scanned, the equations are converted by action routines embedded in the grammar into abstract expression trees. Whilst in this form several tree walks are performed to gather information about lags and to carry out reduction of the left hand side of the equation (if required). The final form of the expression tree is then processed into an intermediate form of the postfix code required by the interpreter. At this stage the final addresses are not yet known. When all of the equations have been read final error checking takes place and the intermediate postfix forms of the equations are converted into their final form and written to the output code file.
+r
-s +s
+onum
Don't include line numbers in error messages Include line numbers in any error messages (default). Assume an infinite number of lines of error messages may be written to the standard output. This option is useful if the error messages and other informative output is to be collected in a file or if working at a paper terminal. Pause and request user instruction before writing the num·th. line of error messages and other output. This option is useful when a large number of messages is expected; one can study the messages before they flash off the top of the screen. The default for this option is +v25 which works fine on IBM compatible machines (with a 25 line screen). Indicate errors using a compact notation and indicate at the end of the parse what the errors were. This is useful if you are an expert or want to conserve paper. Indicate errors less compactly, but more clearly with a message marking and detailing each error (default). Don't include the text of any comments in the output file. This will prevent application programs from recovering the original model structure in the original order. Include the text of any comments in the output file. This makes the output file larger, but is more flexible. Don't reduce equations to normal form, this option is useful if the application needs the equations in unreduced form, but it means that many applications will not be able to make use of the object file. This is the default, it means do reduce each equation and indicate an error if this is not within the capacity of eel. Don't give any statistics about model sizes and dimensions etc. at the completion of translation (default). Give details of the number of variables equations etc. when the translation is completed successfully. Perform optimisations where possible to combine constants etc.; the level of optimisation attempted increases with num. If num is 0 then no indication is given about potential optimisations and none are carried out. The default is +01 meaning that potential optimisations and inefficiencies are indicated, but not removed. Performance of the EEL Translator
The size of the EEL program is about 70 kilobytes (IBM PCs and clones); the program allocates memory as required so that there are no unreasonable restrictions on the size of model that can be translated. The size of any single array is limited by the 16 bit index addressing scheme chosen; however, this is unlikely to cause problems for the foreseeable future and can be removed by changing the address size to 24 or 32 bits.
EEL: A Syst e m for Specif\ing and Eyalu
The largest single objects in any model are likely to be the var array, where the variable values are stored, or the data array which holds numeric constants and coefficients. In recent versions of the U.K. Treasury model the first has a size of around 12000, the second 5000, so that there exists considerable room for expansion before the limits are reached (at 65000). Since the simulation programs for the EEL system are not yet complete we have not as yet coded a large realistic model in EEL, however, the program has been tested with several small models and with many test models which were designed to test error reporting and other features of the translation system. To gain some idea of the speed of operation a test model was artifiCially constructed which contains 1300 relatively complex equations. On an IBM PS/2 model 80 (l6MHz. 80386/80387) machine the translator processes this model in around 24 seconds i.e. at a rate of about 53 equations per second. Obviously this result cannot be extended to more realistic models, but it indicates that translation speed will be considerably better than that offered by currently available Fortran compilers. THE EEL INTERPRETER The EEL translator produces a modified postfix code for expressions; the code is for a software interpretive stack machine. The postfix interpreter concept is well known e.g. Gries (1971) chap. 16 and has many advantages in our application. The idea is basically simple, let" be the postfix operator (i.e. "(E) is the postfix code for expression E), then for any binary operation, 0, "(E t 0 E 2 ) is given by "(E t ) "(E 2 ) 0, for a unary operation, ~, "( ~E) translates to "(E) Execution of the postfix code proceeds from left to right with "(E) leaving the result of evaluating E on the top of a stack. The postfix code for a variable or constant is simply "LOADx address" (x-V or D) which obtains the value at address and pushes the result onto the stack. A typical expression such as X + Y gets translated to "LOADV X LOADV Y ADD". The term postflx being used because operators come after their operands. The code produced by the EEL translator has been modified to improve efficiency in that the common arithmetic functions may address simple operands directly, thus if X and Y are both variables the modified post fix code is simply "VADDII X Y" which reduces the number of machine cycles by two. The EEL interpreter procedure is called EINTERP and is written in the C language. Experimental versions of the interpreter have also been coded and tested in Intel 8086 assembly language. Each interpreter instruction consists of from one to five bytes; the first byte determines what the instruction is and is a number between 1 and 255. The commonly occurring value 0 is reserved to act as an illegal instruction thus helping in debugging. The header byte may be followed by one or two indices which are two-byte unsigned numbers and are the arguments, if any, of the instruction. Thus the Intel 8086 byte sequence for the LOADV X instruction is actually "2 XL XH " where 2 is the header, XL and XH are the low and high bytes of the index of X. The interpreter is more fully described in Becker (1988), Features of Software Interpretation The use of an interpreter in the simulation of econometric models has several advantages and also some disadvantages. The main disadvantage is of course speed of execution, however, as will be seen, the penalty is not great and the interpreter can sometimes be faster than expected . There are several advantages; firstly we can match the interpreter to the application so that the code length required to represent our expressions will In general be smaller than that produced by a typical compiler. This means that larger models can be simulated with the same resources. A second advantage of the close matching is that the total cycle of changing
~I()d c l s
555
the model to resimulation can be shortened because the translation process is faster and instead of having to link the resultant object codes together, the simulation program need only read and process the interpretive code. In addition to these more obvious benefits several others accrue from the computational model which has been chosen in our specific domain. For example we have chosen to provide pointers to the start of each equation rather than a single code block for the whole model, this means that equations can be easily deleted or their order altered at run time. Similarly if one wishes to change the method of solution one need only change the final storage instruction for some or all of the equations. These advantages come from complete knowledge of the coded equation structure, something that is almost impossible with a compiled approach. Another important advantage lies in the area of error recovery; the interpreter always knows what instruction is being performed so it is much easier to provide human oriented error messages or suitable default values when things go wrong with the simulating model. A typical run time error message such as "NEGATIVE LOG LINE 259 OF ROUTINE E91" can be replaced by something like a pointer to the original model text where the error occurred. A program, LEE, has already been written that can reproduce the original model text from the coded form. A final benefit of using an interpreter is that the interpretive model can be changed. This means for example that by using a different interpretation of the code one can evaluate not only the values of expressions, but also the values of derivatives of expressions using the idea of automatic differentiation c.f. Rail (1981). This approach can be extended in other ways using other arithmetics e.g. interval arithmetic could be used to determine upper and lower bounds etc. A start has been made on a differentiating interpreter called DEINTERP see Becker (1988). Operation of the Interpreter The interpreter is relatively easy to understand; it has a program counter, pc, an array of code starts, vcs, a stack pointer, sp, and a stack, stack . In addition there are several data arrays which contain or receive variable values etc .. The most important of these are var which contains the current and lagged values for the variables and data an array which contains the values of constants and coefficients. The interpreter is given a list, nextvx, containing indices of the equations to be evaluated. The interpreter sequences through the list of equations to be solved setting both the current variable index, CVX, and initialising the program counter, pc, to the start of the code for the variable which is held in vcs[cvx} . The interpreter then begins evaluation of the equation or expression. During each inner interpreter cycle the location pointed at by the program counter is evaluated and the program counter incremented. The code extracted is used to select one branch of a large switch statement. The appropriate operations are performed on the evaluation stack, program counter and data arrays. In the case of the simple stack ADD code the operations are as follows sp[-lJ +- sp[Ol; I*add top to top-l*1 sp - -; I*set top - top - 1*1 There are similar sequences for all the familiar arithmetic operations. In order to be able to perform arithmetic, values must be loaded onto the stack; a typical instruction that does just this is the LOADV instruction which takes an index, I, directly from the code and pushes the value var[1J onto the stack and also adjusts the program counter to point after the extracted index. The coding for this instruction is *++sp - var[*«((index *)pc)++)]; which is compact and utterly opaque. When the result of an equation evaluation is to be stored a STOREV instruction can be used to pop the top stack element into the current period value for the current variable using the array, VVS, which holds the appropriate index
R. G. Beeker
556 in var for each variable. Interpreter Performance
At the outset of the EEL project the decision to use an interpreter was made based on the knowledge that floating point arithmetic operations are much slower in general than the simple indexing and integer operations required by the interpreter operation . It seemed likely therefore that, for the sort of desk top machines being considered, the floating point operations would dominate and that the interpretive approach would not be as inefficient as might be expected. Tests carried out using an IBM PS/2 model 80 (80386/80387 16Mhz.) machine running PC-DOS 3.3. These tests confirm our earlier prediction and show, that when the match between the stack based software and the hardware is good (as is the case with 80x87 coprocessors), interpreters can be extremely effective indeed. The tests were carried out for the following types of code 1) Inline: the equations were coded in C with all variable and data references being regarded as constant indexed array references. This is probably the fastest way in which such coding could be done. 2) Amodel: the equations were coded in C following AMODEL style FORTRAN see Rampton 1979. 3) C-Interp: This is a C coded version of the interpreter . 4) A-Interp: This is an assembler coded version of the interpreter which makes good use of the 80x87 maths coprocessor . In particular it makes use of the 80x87's internal stack to minimise data transfer. The tests were carried out by finding the average time required to evaluate equations coded in the different styles. The results are shown in table 1 which shows the times for evaluation of a single equation. The test equations had the following forms
+ ct .ln Vt + c,.ln v, + c 3.ln V3 + c 4.ln V4 + adj )
1)
v = exp(
2) 3) 4) S)
v = exp( In Vt.(v, - V3)/v4 + exp( ln Vt.(v, - v3)/v 4 + v v ln Vt.(v, - v3)lv. + Co v Vt - v, V Vt 1 v,
6)
Co
Co
+ adj )
Co )
The test results shown above indicate that the C coded interpreter is nearly as good as the AMODEL code and that the assembler coded version is actually better; this is due to the function call overhead of AMODEL
test 1 2 3 4 S 6
Table 1 Test Results with 80387 Inline Amodel C-Interp A-Interp 403JlS SOSJlS 619 JlS 293JlS 3SSJjS 231 JlS 369 JlS 191 JlS 183JjS 333JlS 3SSJlS 227 JlS 212JlS 110JlS 103JlS 219JlS 30JjS 10JlS 64JlS 4SJlS 30JjS 13JlS 68JlS 47 JlS
code. The results for the Inline code are probably biased in that the relatively inefficient built in log and exponential functions were used and because there was little opportunity for the compiler to reuse common subexpressions, however, even when this is taken into account it seems that except for very simple equations the interpretive approach is justified. CONCLUSIONS AND FURTHER WORK The EEL language, translator and interpreters are now virtually complete and only minor modifications and extensions are anticipated. For example the language lacks direct references to variable adjustments and
expectations; this will probably be rectified. Tests reveal that the overall performance is satisfactory and that the programs are easily portable. In addition other programs that have already been produced include LEE which reverses the translation process and converts EEL code files back into readable text and a pair of programs that allow the conversion of EEL code files to and from a machine independent form. Work is currently proceeding on a program, STATOPT, for simulating and optimising models produced by the EEL translator. The program will allow:base file formats variable eliminate
generation from source databases in several with generation of generated and dummy data from the model definition this will many data generation problems.
Simulation using different versions of Gauss-Seidel see Hughes Hallet (1984) and various equation orders with built in iterative techniques for rational expectations. Automatic methods will obtain the optimal relaxation parameters for the iterative solution techniques c.f . Fisher (1984). The reduced equation methods proposed by Nepomiastchy and Ravelli (1983) will also be implemented. Online changes to adjustments, fixing of equations and the like. Model changes without total recompilation using an online editor together with some form of model merging capability. That is we intend to allow the user to add, delete or change equations using some form of model editor . An estimation mechanism will allow online re-estimation of specified parameters. Nonlinear Quasi-Newton optimisation for quadratic costs using 'cheap' linear approximations and a 'proper' nonlinear optimisation method with inequality constraints using derivatives and general cost functions with sparse matrix techniques. References Becker, R.G. (1988). EINTERP and DEINTERP Procedures for Evaluating and Differentiating Expressions. PROPE DP lOO, E.E. Dept. Impertal College, London.
Fisher P. G., Holly S. & Hughes Hallet A.J. (1984) Efficient Solution Techniques for Dynamic Nonlinear Rational Expectations Models. ESRC Macroeconomic Modelltng Bureau DP 4, Warwick Univ., U.K.
Gries
D. (1971). Compiler Construction for Digital Computers. J. Wfley, New York. Hughes Hallett A. J. (1984). Multiparameter Iterative Techniques for Solving Econometric Models. ESRC Macroeconomic Modelling Bureau OP. I, Warwick Unlv., U.K.
Johnson, S. C. (197S). YACC - yet another compiler compiler. Computing Science Technical Report 32, AT&T Bell Labs, Murray Htll, N. J., U .S .A . Karakitsos, E. (1988). Monetary Policy, Exchange Rate Dynamics and the Labour Market. Oxford Economic Papers Vo' 40, No. 4 . Lee, C.W. and Becker, R.G. (1988). The EEL Language and Translator. PROPE DP 110, Electrical Engineering Department, Imperial College.
Nepomiastchy, P. and Ravelli, A. (1983). Adapted Methods for Solving and Optimising QuasiTriangular Econometric Models. Annals of Economic and Social Measurement 6.
Rail, L. B. (1981). Automatic Differentiation: Techniques and Applications. Lecture Notes in Computer Science No. 20, Springer Verlag . Rampton, D. (1979). AMODEL, A Program for Solving Econometric Models. Users Guide. HM Treasury.
Waite,
W .M. (1986).
The
Cost of
Lexical
Analysis.
Software Practice and Experience, Vo!. 16(S),
pp 473-488.
EEL: A SYSTEM FOR SPECIFYING AND EVALUATING ECONOMETRIC MODELS R. G. Becker Dl'p(///II/PI//
oI
Elec/riml E lIgilletrillg. Imperial Colhge, LOlldoll Svrl/ 2BT, L'/\
AbstTact. A project to produce an econometric software system is described in broad detail. The software system wlll eventually comprise a model description language. a translator for the language into an interpreter machine code. interpreters and finally simulation. optimisation and estimation packages. At present the language, translator and interpreters are working and have been tested. Work is proceeding on the simulation and optimisation parts of the system.
INTRODUCTION quarterly model un_real; Ithis is the model header !declare a variable for which there is no data genera te my _trend; !this declares a coefficient coefficient param- 1 2 3 4; Ihere's how to get a time trend and illustrates a date my_ trend - 100*(time-1980:1); fan autoregression !unemp +unemp.l +2unemp.2 +3unemp.3 .. .-0.25xlog(pay) ar(param)unemp - 0.25*1" pay; 'a conditional equation limits unemp to two million if(unemp>2e6) unemp - 2e6; !declare tax exogenous prices and pay endogenous exogenous tax; endogenous pay prices; la wage price spiral pay is a moving average of prices pay - ma(O.1 0.2 0.3)prices; prices - l.l*pay.l; Ifirst lag of pay is written pay .l 'now an un-normalised equation Ithe bal : at the beginning says what we solve it for bal: exports - imports - bal - 0; !we can use other brackets and lag expressions exports/prices - (O.2*diff loglO(pay/prices») .2 ;
Work is being carried out by members of the PROPE group at Imperial College to produce software to assist economists to specify. simulate and perform more complicated computations with econometric models. The work is as yet unfinished. but the broad outlines are as follows:- firstly. we have developed a simple language for specifYing discrete time sets of equations which is called EEL (Econometric Equation Language). Secondly we have written a translator for the language (the program is called EEL) which maps the human oriented EEL language into machine code for a simple stack machine. The actual output of the translator contains a lood deal more than just the code for the equations of course; in fact the machine code file contains sufficient information to allow a second program, LEE(EEL backwards) to reverse the translation process and (modulo white space) produce the original input. The third component of the work involves a pair of interpreters for the stack machine code to allow both evaluation of the equations and when required analytic differentiation of the model. The final part of the project is the incorporation of the interpretation system into a program for simulating and optimising econometric models.
Fia. 1 A Sample of the EEL Language
THE EEL LANGUAGE The language (Lee 1988) which we have developed to specify models is extremely simple and should be learnable in less than an hour; we use a fairly standard character set and simple conventions. A model consists of a header which specifies the name and periodicity (ie the type of timing annual quarterly etc.) of the model; this is then followed by an arbitrary number of declarations and equations. The header and each declaration and equation are terminated by a semicolon. Comments which begin with the character ',. and continue to the end of the line may be inserted anywhere reasonable (Le. not in the middle of some other object like an identifier) . There are some reserved words to allow standard functions to be given names (e.g . 'In' for natural logarithm and 'ma' for moving average etc.) and to allow meaningful declarations. Equations do not have to be normalised and in most cases the EEL translator can figure out which variable is to be solved for in a specific equation. in more complicated cases a simple notation makes this clearer. To illustrate all this figure 1 shows a simple model without any economic meaning.
for i-1 •••• .,n and t-1 •••• .,T. In eqn. 1 Y. E Jl"+tn is a vector of variables at time. t. 9 E Jlo is a vector of time invariant coefficients. ~ represents the maximum lag in variables required and f. g E Rn are possibly time varying functions representing the left and right hand sides of the n equations. The whole raison d'etre of EEL is to get away from the rather abstract formulation in eqn. 1 and represent equations as the econometrician would write them in his papers . Thus instead of using vector notation. variables are referred to using mnemonic identifiers. A model written in EEL consists of comments and statements. comments can begin anywhere in a line and start with the character .,' (exclamation mark) and continue to the end of the line. EEL statements consist of identifiers. constants. operators and some special delimiters. Every EEL statement is terminated by a semicolon (';') character. Comments which occur immediately before and during any EEL statement may be kept in the translator output file and are assumed to be associated with the statement; these comments may be accessed later for use as memory aids etc.
Basic La1l&Uale Elements The EEL language is designed to represent discrete time nonlinear dynamical systems of equations like eqn. 1
55 1
R. G. Bee ke r
552
An EEL identifier is a sequence of characters that starts with an alphabetic letter which may be followed by an arbitrary number of letters, digits or underscores(,_') . The case of the letters is important ie the identifiers 'A3' and 'a3' are different! It would have been possible to use other characters in identifiers which are not required elsewhere in the language, but since £ is not a valid character and $ is, it was deemed better to restrict the language. Al Unemployment An_extremely _ long_ identifier _ is allowed_if _you_wish
periodicity _id discrete annual/yearly biannual triannual quarterly monthly weekly daily Fi".5
predeclares year year, year, year, year, year, year,
semester trimester quarter month week day
maximum subperiod NA NA 2 3 4 12 52 365
Periodicities and Predeclared Variables
be available for all required lags and simulation periods;
(2) endogenous variables are defined by the model Fig. 2 EXamples of EEL Identifiers Constants in EEL are at present all numeric; there are three kinds of constant, real, integer and date. The reals may be given in any reasonable way e.g. fixed point, scientific notation etc. Integer constants are used only to define lags and as the arguments to summation functions, however, reals are not required to contain a decimal point. Date constants consist of two integers separated (without any intervening white space) by a colon (':') character. The f irst integer represents the year and the second the appropriate subperiod. The range allowed for the sub-period depends on the model's periodiCity, the first sub-period is always 1 and in a quarterly model the last is 4 (it would be 12 in a monthly model). At present we cannot distinguish a date from a real in annual models; we also have no notation for dates B.C. although this is only a restriction for archaeological economists. Dates may be used anywhere that a real can and on the right hand of a special operator a which evaluates a variable at a specified date. 1.9 0.8
o
100 .7 0.0
1985 1985:1 1 2 3 etc. 123e-45 .0Ie+l00 0010 0.Oe+l0 lel0 1979:365 etc. etc.
Fig. 3 Examples of Constants The first statement of any EEL model is the model header statement which specifies the model periodicity and the name by which the model is known. periodicity _id
model
modeLid
Fig.4 The Model Header Statement Here per,od'c'ty_,d is the name of a particular periodicity (the allowed values are shown below in fig 5) this is followed by the keyword model and then the model identifier. The statement is terminated by the semicolon character at the end . The model header allows the EEL translator to understand date constants and also to predeclare some special variables. The variable, tlms, is always available and as might be expected it ticks along at a rate of once per period; this variable allows the "eneration of trends and can be used in comparisons with date constants e.". if(time<1988:3) etc. The other variables (if any) that are predeclared depend on the periodicity and are shown in fi"ure 5. In EEL variables correspond to time varyin" quantities with a name; coefficients on the other hand are time invariant. The identifiers for variables should correspond to the names attached to data for the correspondin" variables. Thus if you have data for unemployment which is called unemp then the appropriate name for the EEL model variable would be 'unemp'. Within an EEL model variables are divided into three classes, (I) exogenous variables are assumed to be defined externally, data for this class of variables must
equations and data must be available for all required lags; (3) generated variables are defined by model equations, but no data need be available, this means that generated variables should be finally determined by external data. In EEL the type of a variable can be specified by using a declaration of the ri"ht form although it may not be always necessary to declare a particular variable. exoaenous identifier identifier identifier ; endOBenous identifier identifier identifier; generate identifier identifier identifier; generated identifier identifier ..... identifier; coefficient identifier value; coefficient identifier - value .. .. value ; Fig. 6 Variable and Coefficient Declarations Coefficients are declared in a similar way, but each declaration also has to specify the value or values of the coefficient. Coefficients come in three types, (I) scalar rea Is, (2) sequences of reals for use in moving averages and auto-regressions etc. and finally (3) scalar inte"ers for use as arguments to summations, lag operators and the like. The reasons for having named coefficients are firstly as a mnemonic aid; specific coefficients may appear more than once in the model, "IVIng them a name forces them to be the same . Secondly, it may be necessary to refer to specific coefficients at model simulation time, for example to change some policy reed back parameter etc. However, it is intended that it will be possible to alter the value of any individual constant or constant sequence, that appears in the model, without retranslation . This will include altering the lengths of coefficient sequences in moving averages etc . There are restrictions on the use of identifiers for coefficient sequences; at present a sequence identifier may only appear as an argument of the moving average and autoregression operators. endOBenou8 unemp output gdp; exogenous tax_ rate VA T corporation_tax; coefficient c_gdp - 1.5; ! a scalar real coefficient a_unemp - 0.7 -3.1 prices@1980:1 sequence coefficient sum_ length - 5; , a scalar integer
'a
Fig. 7 Examples of Declarations The only other statements in the EEL language besides the header and declarations are equations and two simple statements which affect equations. Equations come in two forms conditional and unconditional . We have made the assumption that any particular equation is to be used to solve for one variable only; this is normally the case in econometric models. To be more specific, it is required that every equation is associated with either an endogenous or generated variable ( a further class of dummy variables may be introduced later), this allows the translator to unambiguously resolve "roups of cond itional equations. There may be more than one conditional equation associated with a non-exogenous variable, but there can be at most one unconditional
EEL: A System for Specifying and Evalua tin g Eco no metri c Mod els equation. Equation statements take the forms shown in figure 8 below. LHS - RHS; I unconditional identifier: LHS - RHS ;!unconditional for identifier if( condition) LHS - RHS; I conditional if( condition ) identifier : LHS RHS ;Iconditional equations; I following equations can be adjusted identities; I followinll equations cannot be adjusted Fill. 8 Equation Statements and their Modifiers Here LHS and RHS are expressions involving variables etc. It is assumed that the variable for which the equation is to be solved appears unlagged in the LHS expression. In the forms with IdentifIer : the identifier is that of the variable to be solved for ; this is to assist the translator in cases where the LHS expression contains more than one possible candidate for the explained variable. The EEL translator makes several assumptions to ease the modeller's task; a variable will be chosen automatically as the explanatory variable for a given equation using the following rules I)
2)
3)
4)
Candidate variables are those appearing unlagged in the left hand side which are not already known to be exogenous. If the equation is unconditional then remove from the list of candidates those already known to have an unconditional equation (since we don't allow multiple unconditional equations for the same variable). If ther e is only one candidate that must be the explained variable. Otherwise there is an error or the modeller should specify the explained variable using the IdentIfIer : form. Operator
Priority Meaning Associativity or, I boolean disjunction I left and, & 2 left boo lean conjunction na less than 3 < <3 na less than or equal >3 na greater than or equal greater than na 3 > equal to 3 na not equal to na <> 3 left addition 4 + 5 left subtraction left multiplication 6 * / 7 left division power 8 right **, unary plus 9 left + unary minus 9 left left natural logarithm In, log 9 10gl0 9 left base 10 logarithm exp 9 left unary exponential left power of 10 pwrlO 9 sqr left square 9 sqrt left square root 9 9 left absolute value abs min(. .. ) 10 na minimum of arguments max( •.. ) na 10 maximum of arguments left first difference 11 diff lag(j) i'th . lag left 11 diffk{i) left i'th . difference 11 left sum of i terms sum{i) 11 av(j) average of i terms left 11 ma(seq) moving average left 11 ar(seq) autoregression left 11 (, [, { expression group start 12 left ), I,) expression group end 13 left lag operator 14 na @ the at date operator IS na identifier 16 variable/coefficient name na constant 17 na constants Fig. 9 EEL Operators and Expreaion Elements
553
By default equations are assumed to have an error added to the RHS expression; the IdentItIes statement inhibits and the equatIons statement turns on this behaviour . At run time the equations can be adjusted and the identities cannot. We have assumed additive adjustments only as the error term will be correctly modified by the reduction to normal form if the equations are to be reduced. The EEL language allows the normal arithmetic operators for addition etc. and in conditions the relations less than etc. can be used; additionally several non standard notations provide for the evaluation of 10llarithms, movinll averalles etc. Figure 9 summarises the allowed expression operators. The priorities and associativities are chosen to reflect normal usage e .g. we can write a +b<-y/z in a condition and get the expected (a+b)s;(y/z). It is less usual to find the logarithm and exponential fUnctions as operators, however, this allows us to write I,.,(x) as In x and let rid of a pair of parentheses in a common case; since the unary operators associate we can also write exp In y (te y) or more usefully dlff In y to mean the first difference of I,.,(y). Another unusual feature is that we allow expression grouping with any of the pairs '0', '[J' and '()'; this is of benefit in our expected application since the expressions in econometric models can sometimes get rather lonll and the use of parentheses only becomes hard on the eye. The really non-standard features of the EEL language involve the differencing, lagging and averaging operators which are described in more detail below in figure 10 where we assume that I is either a positive integer constant or a positive integer valued coefficient identifier, seq is a constant sequence or a coefficient identifier(of length m, indexed 0 - m-I), n is a positive integer constant, £ is an expression and y is some general variable . It should be noted that our convention for autorellressions and moving averages differs from that which is commonly used; normally ar(s) means some autorellression of order 5, in our notation it means the operator [ I + s.LI (L being the lag operator). Similarly we can have operators such as ar(1.2 2.7) (meaning [1 + 1.2 .L + 2 .7 .L2) which are normally represented otherwise. y . n ( E ). n y @ date diff E diffk(i) E la E
Yt-n
ar(seq) E
Et +
gm
Yt-n Ydate
Et Et E t _.
Et -t E t _.
lagged variable lagged expression variable value at date differenced expression i'th. differenced expression i'th. lag of expression
m-I
L seq •. Et_•• ,autoregression
of expression
i-O ma(seq) E
sum(i) E
m-I
L seq•.E t _.
moving average
LE
sum of expression lags
i-O i-I
j-O av(i) E
I 7
1
t -J
i-I •
LE'-J
average of expression lags
j-O
Fil. 10 Non-standard Operators in EEL
Features of the EEL Langualle The EEL language was deSigned to achieve several main loals which include sufficiency, simplicity and ease of translation. The present version of EEL is probably not sufficient to represent all econometric models easily; there is no mechanism for representing expectations (or positive lags) or vector/matrix variables and operators. Similarly there are no conditional blocks (i.e. groups of equations delimited by If then else ete.>, this omission was deliberate . When model texts become large it
554
R. G. Becker
becomes all too easy to forget that part of an equation is in another part of the model merely because there was a convenient conditional block. When there are many switched equations with the same condition our notation will inevitably lead to some inefficiency. The notation used to indicate lags of variables and expressions (i.e. "object . lag") was chosen because it is textually short in that no parentheses are needed and since we don't cater for positive or variable lags no minus sign is required. The restriction of lags to constants is unlikely to cause many problems, there can't be very many cases in which the lag on a variable depends on the value of some other model variable. Another major deficiency is that there is no method of distinguishing estimated from imposed coefficients or that a particular coefficient/constant has a variance or other statistical properties attached to it. The present translator program is also unable to reduce arbitrary left hand sides, but will cope with most common cases. The need to associate each equation with a particular non-exogenous variable is due firstly to the fact that the most popular methods of econometric model solution c.f. Hughes Hallett (1984) or Fisher et al. (1984) demand reduced form equations and also to the ambiguity problem when conditional equations are allowed (see figure 11 below; the result depends on whether the conditional equation holds and which variable it is for). This in turn leads to the use of the colon to mean Is explained by (see fig. 8).
A-a. B-11
Operation of the Translator To translate a model from source into the form required by the simulation and other programs the program eel is invoked as follows eel (options] modBlfll_ (outputfllename] where the terms in brackets may be omitted. The modelfllename is the name of (or path to) the source containing the model text. The outputfllename is the name of (or path to) the file which is to receive the interpreter code; if this name is omitted then the name "out.mc" is assumed. The options control certain aspects of the translator's operation and are as follows -I
+1 -v
+vnum
- m
ire condition) A/B - "'f Fig. 11 Ambiguous System of Equations +m On the other hand the language itself is extremely simple and there are few restrictions, this makes it both easy to learn and use and also easy to translate. This means that it will speed up the process of change of conceptual model to final simulation.
-c
THE EEL TRANSLATOR -r
The translator program for EEL is written in the C language; the translator is called EEL and is up and working on IBM PC machines running MS/PC-DOS, on DEC VAX lIs running BSD Unix 4.2/4.3 and IBM's risc based RT 6150' running either BSD Unix 4.3 (which IBM calls AOS) or AIX, IBM's own version of UNIX. The translator is designed along fairly well known lines; the grammar for the EEL language was transcribed into the format required by the Y ACC compiler compiler (Johnson (1976» which was then translated using YACC into a table driven parser for EEL. Since speed of translation was considered crucial the lexical analyser for the translator was hand written using the approach recommended by Waite (1986). Translation of the equations proceeds in three main passes; in the first pass, which occurs as the input text is being scanned, the equations are converted by action routines embedded in the grammar into abstract expression trees. Whilst in this form several tree walks are performed to gather information about lags and to carry out reduction of the left hand side of the equation (if required). The final form of the expression tree is then processed into an intermediate form of the postfix code required by the interpreter. At this stage the final addresses are not yet known. When all of the equations have been read final error checking takes place and the intermediate postfix forms of the equations are converted into their final form and written to the output code file.
+r
-s +s
+onum
Don't include line numbers in error messages Include line numbers in any error messages (default). Assume an infinite number of lines of error messages may be written to the standard output. This option is useful if the error messages and other informative output is to be collected in a file or if working at a paper terminal. Pause and request user instruction before writing the num·th. line of error messages and other output. This option is useful when a large number of messages is expected; one can study the messages before they flash off the top of the screen. The default for this option is +v25 which works fine on IBM compatible machines (with a 25 line screen). Indicate errors using a compact notation and indicate at the end of the parse what the errors were. This is useful if you are an expert or want to conserve paper. Indicate errors less compactly, but more clearly with a message marking and detailing each error (default). Don't include the text of any comments in the output file. This will prevent application programs from recovering the original model structure in the original order. Include the text of any comments in the output file. This makes the output file larger, but is more flexible. Don't reduce equations to normal form, this option is useful if the application needs the equations in unreduced form, but it means that many applications will not be able to make use of the object file. This is the default, it means do reduce each equation and indicate an error if this is not within the capacity of eel. Don't give any statistics about model sizes and dimensions etc. at the completion of translation (default). Give details of the number of variables equations etc. when the translation is completed successfully. Perform optimisations where possible to combine constants etc.; the level of optimisation attempted increases with num. If num is 0 then no indication is given about potential optimisations and none are carried out. The default is +01 meaning that potential optimisations and inefficiencies are indicated, but not removed. Performance of the EEL Translator
The size of the EEL program is about 70 kilobytes (IBM PCs and clones); the program allocates memory as required so that there are no unreasonable restrictions on the size of model that can be translated. The size of any single array is limited by the 16 bit index addressing scheme chosen; however, this is unlikely to cause problems for the foreseeable future and can be removed by changing the address size to 24 or 32 bits.
EEL: A Syst e m for Specif\ing and Eyalu
The largest single objects in any model are likely to be the var array, where the variable values are stored, or the data array which holds numeric constants and coefficients. In recent versions of the U.K. Treasury model the first has a size of around 12000, the second 5000, so that there exists considerable room for expansion before the limits are reached (at 65000). Since the simulation programs for the EEL system are not yet complete we have not as yet coded a large realistic model in EEL, however, the program has been tested with several small models and with many test models which were designed to test error reporting and other features of the translation system. To gain some idea of the speed of operation a test model was artifiCially constructed which contains 1300 relatively complex equations. On an IBM PS/2 model 80 (l6MHz. 80386/80387) machine the translator processes this model in around 24 seconds i.e. at a rate of about 53 equations per second. Obviously this result cannot be extended to more realistic models, but it indicates that translation speed will be considerably better than that offered by currently available Fortran compilers. THE EEL INTERPRETER The EEL translator produces a modified postfix code for expressions; the code is for a software interpretive stack machine. The postfix interpreter concept is well known e.g. Gries (1971) chap. 16 and has many advantages in our application. The idea is basically simple, let" be the postfix operator (i.e. "(E) is the postfix code for expression E), then for any binary operation, 0, "(E t 0 E 2 ) is given by "(E t ) "(E 2 ) 0, for a unary operation, ~, "( ~E) translates to "(E) Execution of the postfix code proceeds from left to right with "(E) leaving the result of evaluating E on the top of a stack. The postfix code for a variable or constant is simply "LOADx address" (x-V or D) which obtains the value at address and pushes the result onto the stack. A typical expression such as X + Y gets translated to "LOADV X LOADV Y ADD". The term postflx being used because operators come after their operands. The code produced by the EEL translator has been modified to improve efficiency in that the common arithmetic functions may address simple operands directly, thus if X and Y are both variables the modified post fix code is simply "VADDII X Y" which reduces the number of machine cycles by two. The EEL interpreter procedure is called EINTERP and is written in the C language. Experimental versions of the interpreter have also been coded and tested in Intel 8086 assembly language. Each interpreter instruction consists of from one to five bytes; the first byte determines what the instruction is and is a number between 1 and 255. The commonly occurring value 0 is reserved to act as an illegal instruction thus helping in debugging. The header byte may be followed by one or two indices which are two-byte unsigned numbers and are the arguments, if any, of the instruction. Thus the Intel 8086 byte sequence for the LOADV X instruction is actually "2 XL XH " where 2 is the header, XL and XH are the low and high bytes of the index of X. The interpreter is more fully described in Becker (1988), Features of Software Interpretation The use of an interpreter in the simulation of econometric models has several advantages and also some disadvantages. The main disadvantage is of course speed of execution, however, as will be seen, the penalty is not great and the interpreter can sometimes be faster than expected . There are several advantages; firstly we can match the interpreter to the application so that the code length required to represent our expressions will In general be smaller than that produced by a typical compiler. This means that larger models can be simulated with the same resources. A second advantage of the close matching is that the total cycle of changing
~I()d c l s
555
the model to resimulation can be shortened because the translation process is faster and instead of having to link the resultant object codes together, the simulation program need only read and process the interpretive code. In addition to these more obvious benefits several others accrue from the computational model which has been chosen in our specific domain. For example we have chosen to provide pointers to the start of each equation rather than a single code block for the whole model, this means that equations can be easily deleted or their order altered at run time. Similarly if one wishes to change the method of solution one need only change the final storage instruction for some or all of the equations. These advantages come from complete knowledge of the coded equation structure, something that is almost impossible with a compiled approach. Another important advantage lies in the area of error recovery; the interpreter always knows what instruction is being performed so it is much easier to provide human oriented error messages or suitable default values when things go wrong with the simulating model. A typical run time error message such as "NEGATIVE LOG LINE 259 OF ROUTINE E91" can be replaced by something like a pointer to the original model text where the error occurred. A program, LEE, has already been written that can reproduce the original model text from the coded form. A final benefit of using an interpreter is that the interpretive model can be changed. This means for example that by using a different interpretation of the code one can evaluate not only the values of expressions, but also the values of derivatives of expressions using the idea of automatic differentiation c.f. Rail (1981). This approach can be extended in other ways using other arithmetics e.g. interval arithmetic could be used to determine upper and lower bounds etc. A start has been made on a differentiating interpreter called DEINTERP see Becker (1988). Operation of the Interpreter The interpreter is relatively easy to understand; it has a program counter, pc, an array of code starts, vcs, a stack pointer, sp, and a stack, stack . In addition there are several data arrays which contain or receive variable values etc .. The most important of these are var which contains the current and lagged values for the variables and data an array which contains the values of constants and coefficients. The interpreter is given a list, nextvx, containing indices of the equations to be evaluated. The interpreter sequences through the list of equations to be solved setting both the current variable index, CVX, and initialising the program counter, pc, to the start of the code for the variable which is held in vcs[cvx} . The interpreter then begins evaluation of the equation or expression. During each inner interpreter cycle the location pointed at by the program counter is evaluated and the program counter incremented. The code extracted is used to select one branch of a large switch statement. The appropriate operations are performed on the evaluation stack, program counter and data arrays. In the case of the simple stack ADD code the operations are as follows sp[-lJ +- sp[Ol; I*add top to top-l*1 sp - -; I*set top - top - 1*1 There are similar sequences for all the familiar arithmetic operations. In order to be able to perform arithmetic, values must be loaded onto the stack; a typical instruction that does just this is the LOADV instruction which takes an index, I, directly from the code and pushes the value var[1J onto the stack and also adjusts the program counter to point after the extracted index. The coding for this instruction is *++sp - var[*«((index *)pc)++)]; which is compact and utterly opaque. When the result of an equation evaluation is to be stored a STOREV instruction can be used to pop the top stack element into the current period value for the current variable using the array, VVS, which holds the appropriate index
R. G. Beeker
556 in var for each variable. Interpreter Performance
At the outset of the EEL project the decision to use an interpreter was made based on the knowledge that floating point arithmetic operations are much slower in general than the simple indexing and integer operations required by the interpreter operation . It seemed likely therefore that, for the sort of desk top machines being considered, the floating point operations would dominate and that the interpretive approach would not be as inefficient as might be expected. Tests carried out using an IBM PS/2 model 80 (80386/80387 16Mhz.) machine running PC-DOS 3.3. These tests confirm our earlier prediction and show, that when the match between the stack based software and the hardware is good (as is the case with 80x87 coprocessors), interpreters can be extremely effective indeed. The tests were carried out for the following types of code 1) Inline: the equations were coded in C with all variable and data references being regarded as constant indexed array references. This is probably the fastest way in which such coding could be done. 2) Amodel: the equations were coded in C following AMODEL style FORTRAN see Rampton 1979. 3) C-Interp: This is a C coded version of the interpreter . 4) A-Interp: This is an assembler coded version of the interpreter which makes good use of the 80x87 maths coprocessor . In particular it makes use of the 80x87's internal stack to minimise data transfer. The tests were carried out by finding the average time required to evaluate equations coded in the different styles. The results are shown in table 1 which shows the times for evaluation of a single equation. The test equations had the following forms
+ ct .ln Vt + c,.ln v, + c 3.ln V3 + c 4.ln V4 + adj )
1)
v = exp(
2) 3) 4) S)
v = exp( In Vt.(v, - V3)/v4 + exp( ln Vt.(v, - v3)/v 4 + v v ln Vt.(v, - v3)lv. + Co v Vt - v, V Vt 1 v,
6)
Co
Co
+ adj )
Co )
The test results shown above indicate that the C coded interpreter is nearly as good as the AMODEL code and that the assembler coded version is actually better; this is due to the function call overhead of AMODEL
test 1 2 3 4 S 6
Table 1 Test Results with 80387 Inline Amodel C-Interp A-Interp 403JlS SOSJlS 619 JlS 293JlS 3SSJjS 231 JlS 369 JlS 191 JlS 183JjS 333JlS 3SSJlS 227 JlS 212JlS 110JlS 103JlS 219JlS 30JjS 10JlS 64JlS 4SJlS 30JjS 13JlS 68JlS 47 JlS
code. The results for the Inline code are probably biased in that the relatively inefficient built in log and exponential functions were used and because there was little opportunity for the compiler to reuse common subexpressions, however, even when this is taken into account it seems that except for very simple equations the interpretive approach is justified. CONCLUSIONS AND FURTHER WORK The EEL language, translator and interpreters are now virtually complete and only minor modifications and extensions are anticipated. For example the language lacks direct references to variable adjustments and
expectations; this will probably be rectified. Tests reveal that the overall performance is satisfactory and that the programs are easily portable. In addition other programs that have already been produced include LEE which reverses the translation process and converts EEL code files back into readable text and a pair of programs that allow the conversion of EEL code files to and from a machine independent form. Work is currently proceeding on a program, STATOPT, for simulating and optimising models produced by the EEL translator. The program will allow:base file formats variable eliminate
generation from source databases in several with generation of generated and dummy data from the model definition this will many data generation problems.
Simulation using different versions of Gauss-Seidel see Hughes Hallet (1984) and various equation orders with built in iterative techniques for rational expectations. Automatic methods will obtain the optimal relaxation parameters for the iterative solution techniques c.f . Fisher (1984). The reduced equation methods proposed by Nepomiastchy and Ravelli (1983) will also be implemented. Online changes to adjustments, fixing of equations and the like. Model changes without total recompilation using an online editor together with some form of model merging capability. That is we intend to allow the user to add, delete or change equations using some form of model editor . An estimation mechanism will allow online re-estimation of specified parameters. Nonlinear Quasi-Newton optimisation for quadratic costs using 'cheap' linear approximations and a 'proper' nonlinear optimisation method with inequality constraints using derivatives and general cost functions with sparse matrix techniques. References Becker, R.G. (1988). EINTERP and DEINTERP Procedures for Evaluating and Differentiating Expressions. PROPE DP lOO, E.E. Dept. Impertal College, London.
Fisher P. G., Holly S. & Hughes Hallet A.J. (1984) Efficient Solution Techniques for Dynamic Nonlinear Rational Expectations Models. ESRC Macroeconomic Modelltng Bureau DP 4, Warwick Univ., U.K.
Gries
D. (1971). Compiler Construction for Digital Computers. J. Wfley, New York. Hughes Hallett A. J. (1984). Multiparameter Iterative Techniques for Solving Econometric Models. ESRC Macroeconomic Modelling Bureau OP. I, Warwick Unlv., U.K.
Johnson, S. C. (197S). YACC - yet another compiler compiler. Computing Science Technical Report 32, AT&T Bell Labs, Murray Htll, N. J., U .S .A . Karakitsos, E. (1988). Monetary Policy, Exchange Rate Dynamics and the Labour Market. Oxford Economic Papers Vo' 40, No. 4 . Lee, C.W. and Becker, R.G. (1988). The EEL Language and Translator. PROPE DP 110, Electrical Engineering Department, Imperial College.
Nepomiastchy, P. and Ravelli, A. (1983). Adapted Methods for Solving and Optimising QuasiTriangular Econometric Models. Annals of Economic and Social Measurement 6.
Rail, L. B. (1981). Automatic Differentiation: Techniques and Applications. Lecture Notes in Computer Science No. 20, Springer Verlag . Rampton, D. (1979). AMODEL, A Program for Solving Econometric Models. Users Guide. HM Treasury.
Waite,
W .M. (1986).
The
Cost of
Lexical
Analysis.
Software Practice and Experience, Vo!. 16(S),
pp 473-488.