108—Chapter 6. EViews Programming
Note that if SER1 contains missing values, the corresponding value of TEST will also be missing. Since the @sum function ignores missing values, the program does not halt for SER1 that has missing values, as long as there is no negative value.
Sometimes, you do not wish to stop the entire program when a condition is satisfied; you just wish to exit the current loop. The exitloop command will exit the current for or while statement and continue running the program.
For example, suppose you computed a sequence of LR test statistics LR11, LR10, LR9, ..., LR1, say to test the lag length of a VAR. The following program sequentially carries out the LR test starting from LR11 and tells you the statistic that is first rejected at the 5% level:
!df = 9
for !lag = 11 to 1 step -1
!pval = 1 - @cchisq(lr{!lag},!df) if !pval<=.05 then
exitloop endif
next
scalar lag=!lag
Note that the scalar LAG has the value 0 if none of the test statistics are rejected.
Multiple Program Files
When working with long programs, you may wish to organize your code using multiple files. For example, suppose you have a program file named POWERS.PRG which contains a set of program lines that you wish to use.
While you may be tempted to string files together using the run command, we caution you that EViews will stop after executing the commands in the referenced file. Thus, a program containing the lines
run powers.prg
series x = nrnd
will only execute the commands in the file POWERS, and will stop before generating the series X. This behavior is probably not what you intended.
You should instead use the include keyword to include the contents of a program file in another program file. For example, you can place the line
Subroutines—109
include powers
at the top of any other program that needs to use the commands in POWERS. include also accepts a full path to the program file, and you may have more than one include statement in a program. For example, the lines,
include c:\programs\powers.prg
include durbin_h
[more lines]
will first execute all of the commands in C:\PROGRAMS\POWERS.PRG, then will execute the commands in DURBIN_H.PRG, and then will execute the remaining lines in the program file.
Subroutines provide a more general, alternative method of reusing commands and using arguments.
Subroutines
A subroutine is a collection of commands that allows you to perform a given task repeatedly, with minor variations, without actually duplicating the commands. You can also use subroutines from one program to perform the same task in other programs.
Defining Subroutines
A subroutine starts with the keyword subroutine followed by the name of the routine and any arguments, and ends with the keyword endsub. Any number of commands can appear in between. The simplest type of subroutine has the following form:
subroutine z_square
series x = z^2
endsub
where the keyword subroutine is followed only by the name of the routine. This subroutine has no arguments so that it will behave identically every time it is used. It forms the square of the existing series Z and stores it in the new series X.
You can use the return command to force EViews to exit from the subroutine at any time. A common use of return is to exit from the subroutine if an unanticipated error is detected. The following program exits the subroutine if Durbin’s h statistic for testing serial correlation with a lagged dependent variable cannot be computed (for details, see Greene, 1997, p.596, or Davidson and MacKinnon, 1993, p. 360):
subroutine durbin_h
equation eqn.ls cs c cs(-1) inc
scalar test=1-eqn.@regobs*eqn.@cov(2,2)
110—Chapter 6. EViews Programming
'an error is indicated by test being nonpositive
'exit on error
if test<=0 then return
endif
' compute h statistic if test positive scalar h=(1-eqn.@dw/2)*sqr(eqn.@regobs/test) endsub
Subroutine with arguments
The subroutines so far have been written to work with a specific set of variables. More generally, subroutines can take arguments. If you are familiar with another programming language, you probably already know how arguments allow you to change the behavior of the group of commands each time the subroutine is used. Even if you haven’t encountered subroutines, you are probably familiar with similar concepts from mathematics. You can define a function, say
f(x) = x2 |
(6.1) |
where f depends upon the argument x . The argument x is merely a place holder—it’s there to define the function and it does not really stand for anything. Then, if you want to evaluate the function at a particular numerical value, say 0.7839, you can write
f(0.7839 ) . If you want to evaluate the function at a different value, say 0.50123, you merely write f(0.50123 ) . By defining the function, you save yourself from writing out the whole expression every time you wish to evaluate it for a different value.
To define a subroutine with arguments, you start with subroutine, followed by the subroutine name, a left parenthesis, the arguments separated by commas, and finally a right parenthesis. Each argument is specified by listing a type of EViews object, followed by the name of the argument. Control variables may be passed by the scalar type and string variables by the string type. For example:
subroutine power(series v, series y, scalar p)
v = y^p
endsub
This subroutine generalizes the example subroutine Z_SQUARE. Calling POWER will fill the series given by the argument V with the power P of the series specified by the argument Y. So if you set V equal to X, Y equal to Z, and P equal to 2, you will get the equivalent of the subroutine Z_SQUARE above. See the discussion below on how to call subroutines.
Subroutines—111
Subroutine Placement
Your subroutine definitions should be placed, in any order, at the beginning of your program. The subroutines will not be executed until they are executed by the program using a call statement. For example:
subroutine z_square
series x=z^2
endsub
' start of program execution
load mywork
fetch z
call z_square
Execution of this program begins with the load statement; the subroutine definition is skipped and is executed only at the last line when it is “called.”
The subroutine definitions must not overlap—after the subroutine keyword, there should be an endsub before the next subroutine declaration. Subroutines may call each other, or even call themselves.
Alternatively, you may wish to place frequently used subroutines in a separate program file and use an include statement to insert them at the beginning of your program. If, for example, you put the subroutine lines in the file POWERS.PRG, then you may put the line:
include powers
at the top of any other program that needs to call Z_SQUARE or POWER. You can use the subroutines in these programs as though they were built-in parts of the EViews programming language.
Calling Subroutines
Once a subroutine is defined, you may execute the commands in the subroutine by using the call keyword. call should be followed by the name of the subroutine, and a list of any argument values you wish to use, enclosed in parentheses and separated by commas. If the subroutine takes arguments, they must all be provided in the same order as in the declaration statement. Here is an example program file that calls subroutines:
include powers
load mywork
fetch z gdp
series x
112—Chapter 6. EViews Programming
series gdp2
series gdp3
call z_square
call power(gdp2,gdp,2)
call power(gdp3,gdp,3)
The first call fills the series X with the value of Z squared. The second call creates the series GDP2 which is GDP squared. The last call creates the series GDP3 as the cube of GDP.
When the subroutine argument is a scalar, the subroutine may be called with a scalar object, a control variable, a simple number (such as “10” or “15.3”), a matrix element (such as “mat1(1,2)”) or a scalar expression (such as “!y+25”). Subroutines that take matrix and vector arguments can be called with a matrix name, and if not modified by the subroutine, may also take a matrix expression. All other arguments must be passed to the subroutine with a simple object (or string) name referring to a single object of the correct type.
Global and Local Variables
Subroutines work with variables and objects that are either global or local.
Global variables refer either to objects which exist in the workfile when the subroutine is called, or to the objects that are created in the workfile by a subroutine. Global variables remain in the workfile when the subroutine finishes.
A local variable is one that has meaning only within the subroutine. Local variables are deleted from the workfile once a subroutine finishes. The program that calls the subroutine will not know anything about a local variable since the local variable will disappear once the subroutine finishes and returns to the original program.
Global Subroutines
By default, subroutines in EViews are global. Any global subroutine may refer to any global object that exists in the workfile at the time the subroutine is called. Thus, if Z is a series in the workfile, the subroutine may refer to and, if desired, alter the series Z. Similarly, if Y is a global matrix that has been created by another subroutine, the current subroutine may use the matrix Y.
The rules for variables in global subroutines are:
•Newly created objects are global and will be included in the workfile when the subroutine finishes.
Subroutines—113
•Global objects may be used and updated directly from within the subroutine. If, however, a global object has the same name as an argument in a subroutine, the variable name will refer to the argument and not to the global variable.
•The global objects corresponding to arguments may be used and updated by referring to the arguments.
Here is a simple program that calls a global subroutine:
subroutine z_square
series x = z^2
endsub
load mywork
fetch z
call z_square
Z_SQUARE is a global subroutine which has access to the global series Z. The new global series X contains the square of the series Z. Both X and Z remain in the workfile when Z_SQUARE is finished.
If one of the arguments of the subroutine has the same name as a global variable, the argument name takes precedence. Any reference to the name in the subroutine will refer to the argument, not to the global variable. For example:
subroutine sqseries(series z,string %name)
series {%name} = z^2
endsub
load mywork
fetch z
fetch y
call sqseries(y,"y2")
In this example, there is a series Z in the original workfile and Z is also an argument of the subroutine. Calling SQSERIES with the argument set to Y tells EViews to use the argument rather than the global Z. Upon completion of the routine, a new series Y2 will contain the square of the series Y, not the square of the series Z.
Global subroutines may call global subroutines. You should make certain to pass along any required arguments when you call a subroutine from within a subroutine. For example,
subroutine wgtols(series y, series wt)
equation eq1
call ols(eq1, y)
equation eq2
114—Chapter 6. EViews Programming
series temp = y/sqr(wt) call ols(eq2,temp) delete temp
endsub
subroutine ols(equation eq, series y) eq.ls y c y(-1) y(-1)^2 y(-1)^3
endsub
can be run by the program:
load mywork
fetch cpi
fetch cs
call wgtols(cs,cpi)
In this example, the subroutine WGTOLS explicitly passes along the arguments for EQ and Y to the subroutine OLS; otherwise those arguments would not be recognized by OLS. If EQ and Y were not passed, OLS would try to find a global series named Y and a global equation named EQ, instead of using EQ1 and CS or EQ2 and TEMP.
You cannot use a subroutine to change the object type of a global variable. Suppose that we wish to declare new matrices X and Y by using a subroutine NEWXY. In this example, the declaration of the matrix Y works, but the declaration of matrix X generates an error because a series named X already exists:
subroutine newxy matrix(2,2) x = 0 matrix(2,2) y = 0
endsub
load mywork series x call newxy
EViews will return an error indicating that the global series X already exists and is of a different type than a matrix.
Local Subroutines
All objects created by a global subroutine will be global and will remain in the workfile upon exit from the subroutine. If you include the word local in the definition of the subroutine, you create a local subroutine. All objects created by a local subroutine will be local and will be removed from the workfile upon exit from the subroutine. Local subroutines
Subroutines—115
are most useful when you wish to write a subroutine which creates many temporary objects that you do not want to keep.
The rules for variables in local subroutines are:
•You may not use or update global objects directly from within the subroutine.
•The global objects corresponding to arguments may be used and updated by referring to the arguments.
•All other objects in the subroutine are local and will vanish when the subroutine finishes.
If you want to save results from a local subroutine, you have to explicitly include them in the arguments. For example, consider the subroutine:
subroutine local ols(series y, series res, scalar ssr) equation temp_eq.ls y c y(-1) y(-1)^2 y(-1)^3 temp_eq.makeresid res
ssr = temp_eq.@ssr endsub
This local subroutine takes the series Y as input and returns the series RES and scalar SSR as output. The equation object TEMP_EQ is local to the subroutine and will vanish when the subroutine finishes.
Here is an example program that calls this local subroutine:
load mywork fetch hsf
equation eq1.ls hsf c hsf(-1) eq1.makeresid rres
scalar rssr = eq1.@ssr series ures
scalar ussr
call ols(hsf, ures, ussr)
Note how we first declare the series URES and scalar USSR before calling the local subroutine. These objects are global since they are declared outside the local subroutine. When we call the local subroutine by passing these global objects as arguments, the subroutine will update these global variables.
There is one exception to the general inaccessibility of global variables in local subroutines. When a global group is passed as an argument to a local subroutine, any series in the group is accessible to the local routine.