EViews.com

I am trying to estimate a Phillips curve model, following the "triangular" approach of Gordon (1997), in which the basic determinants of the inflation rate are inertia (lagged values of inflation rate), demand pressure (the GDP gap or unemployment gap), and supply shocks (index of food and energy prices). The idea is to use the state space object to estimate the relevant coefficients and generate a time series for the NAIRU (which is not directly observable).

I've written the following code for an EViews state space object:

@signal inflation_rate = c + c(1)*inflation_rate(-1) + c(2)*(ue_gap) + c(3)*fe_index + [var = exp(c(4))]

@signal ue_gap = ue_rate - nairu

@state nairu = nairu(-1) + [var = 0.04]

(I will add further lags. This is just to make sure I have the basic coding correct.)

The first signal equation defines the basic structure of the model.

The second signal equation defines the unemployment gap variable as the difference between the actual unemployment rate and the NAIRU.

The state equation defines the NAIRU (which is not directly observable) as a random walk variable. It sets the variance at 0.04 (following Gordon (1997), who sets the standard deviation for the NAIRU at 0.2).

The idea here is to use the Kalman filter process to estimate the coefficients and generate the NAIRU series.

I would appreciate feedback on whether the EViews coding is correct to achieve what I have described.

You seem to be doing what you think you should be doing. However, I think you accidentally misspecified the constant "c" in your signal equation. Since all signal variables must have observed values, you should rewrite the second signal equation. Please note that the unemployment gap is also an unobserved variable, which must be explicitly specifed as a state variable. You can define any specific forms for the gap variable ranging from pure noise to random walk. AR(1) or AR(2) specifications are also common in the practice. The final version of your code should be something like the following:
The last line makes sure that each time you run the model the starting values will equal to zero.

@trubador, Thanks for your reply. It is very helpful.

Two of the changes you made to my code seem clear:

1) The need to specify the constant term in the first signal equation in the form c(n).

2) The need to have the left-hand variable in the second signal equation be an observable variable, so the need to rearrange this equation with "ue_rate" on the left-hand side.

Two of the changes I do not understand:

1) The state equation for "ue_gap". The "unemployment gap" is defined as the difference between the actual unemployment rate and the NAIRU (as described in the second signal equation). The specification in the second state equation in your revision looks, to me, like it defines the unemployment gap as pure noise. This would only be true, in general, if the actual unemployment rate were always equal to the NAIRU (which it is not). Am I correct in understanding your text ("You can define any specific forms for the gap variable ranging from pure noise to random walk.") to mean that the second state equation as you have it written is just an example? Would the following state equation be permissible for specifying the unemployment gap?

@state ue_gap = ue_rate - nairu(-1) - [var = 0.04]

This just substitutes the definition of NAIRU in the first state equation into my original second signal equation (defining the unemployment gap). If this is permissible, does it render either the second signal equation or the first state equation (in your version of the code) redundant?

Alternatively, could the unemployment gap be defined by a state equation without an explicit error term?

@state ue_gap = ue_rate - nairu

This is what I originally had as the second signal equation, but which was impermissible in this form since it had an unobservable variable on the left-hand side. NAIRU would still be defined as a random-walk variable by the first state equation.

2) I don't understand the effect of setting all the starting values equal to zero for each run. Are the results obtained sensitive to this initial setting?

Yes, that example was only given for expositional purposes. You can define the unemployment gap in many ways. Unless you impose a certain model for the gap variable, defining NAIRU as a random walk process will probably leave the noise component. As long as you need the unemployment gap as a seperate state variable, you should make sure that you define its own dynamics instead of deriving it. This is a bivariate state space model, which does not leave you much of a choice in that respect.

Since state space analyses can be very data-dependent, you should try alternative specifications and see which one will fit better to your data. If, for example, you believe (or do have a priori information) that the unemployment gap should display cyclical behavior, then you could define it as an AR(2) process.

If you do not explicitly fix the starting values, EViews will use the coefficient values from the previous estimation in each run.

@trubador, Thanks for your quick reply, once again.

I wonder whether the last exchange of messages involves a misunderstanding. For the purposes of the model I have laid out, the "unemployment gap" is, by definition, equal to the actual unemployment rate minus the NAIRU. Thus, an equation of the form ...

(A) ue_gap = ue_rate - nairu

or

(B) ue_rate = ue_gap + nairu

... is an identity.

The first signal equation includes the variable ue_gap as a way to impose a common coefficient estimate for ue_rate and nairu (with opposite signs, obviously).

So I'm confused by the suggestion that, for the unemployment gap variable, I need to "define its own dynamics instead of deriving it." It seems to me that ue_gap is fully defined by two equations:

1) The identity described by either of the two equations (A) or (B) above.

2) The state equation defining NAIRU as a random-walk variable: @state nairu = nairu(-1) + [var = 0.04]. (The variable "ue_rate" is defined in that it is an observable variable.)

I understand that only equation (B) above exhibits correct syntax as a signal equation. Does equation (A) exhibit correct syntax as a state equation? You said that I need a state equation to specify the unobservable variable ue_gap. It is indeed unobservable, because it contains the unobservable component nairu. The question, then, is whether it is alright for a state equation to define a variable in terms of one observable variable and another, nonobservable variable.

In addition, I am hoping for clarification of the following questions:

1) Should the identity defining ue_gap in terms of ue_rate and nairu be a signal equation? A state equation? Or could it be done either way?

2) If it is possible to specify this identity as a state equation ...

@state ue_gap = ue_rate - nairu

then can I omit the signal equation ...

@signal ue_rate = ue_gap + nairu.

Thanks for your help.

As I understand, your confusion is related to state space modeling not to EViews' syntax. Putting the model into state space from is an important task, since you have to follow certain rules. Although some of the alternative specifications you offer seem reasonable, they violate these rules one way or the other. You have to define system matrices correctly in order to proceed to the estimation step. I suggest you to go over the details of state space modeling from a textbook and then take a glance at EViews' examples from the manual or this forum.

I have estimated my model using code similar to what you suggested in your first reply. I have used various different specifications of the state equation for the unemployment gap variable, including pure noise, random walk, and AR(2). Here is the code with the specification of the ue_gap variable as AR(2).

@signal inflation_rate = c(1) + c(2)*inflation_rate(-1) + c(3)*ue_gap + c(4)*food_energy_index + c(5)*import_index + [var = exp(c(6))]

@signal ue_rate = ue_gap + nairu

@state nairu = nairu(-1) + [var = exp(c(7))]

@state ue_gap = ue_gap(-1) + ue_gap1(-1) + [var = exp(c(8))]

@state ue_gap1 = ue_gap(-1)

param c(1) .0 c(2) .0 c(3) .0 c(4) .0 c(5) .0 c(6) .0 c(7) .0 c(8) .0


In the other models, the state equation for the ue_gap is specified as:

Pure noise: @state ue_gap = [var = exp(c(8))]

Random walk: @state ue_gap = ue_gap(-1) + [var = exp(c(8))]

I have also run models in which the variance for the nairu variable is constrained to 0.04 (following Gordon (1997)). In those models, the state equation for the nairu is specified as:

@state nairu = nairu(-1) + [var = 0.04]

Some of the models give reasonable results in terms of coefficient estimates (e.g., theory-consistent signs), but give TV-NAIRU series that are clearly not right. Both the pure noise and AR(2) specifications give series that closely follow the path of the actual unemployment rate. Using the random-walk specification yields a NAIRU series that (while increasing in the late 1970s, which seems plausible) runs at around 2% from the late 1950s to the mid 1970s. That makes the unemployment gap (= UE rate - NAIRU) substantially positive even during the period of lowest unemployment in the late 1960s, and implies that the unemployment level even during that period was strongly deflationary. So that's clearly not correct. I haven't come close to a reasonable-looking TV-NAIRU series (where it oscillates around 6% or so).

Finally, I tried an approach that did not use an unemployment gap variable ("ue_gap") requiring further definition in a state equation, but instead just specified the variable directly as "(ue_rate - nairu)" in the main signal equation and used just one state equation (describing the NAIRU as a random walk variable). This did not seem to create any syntax problem, and EViews did estimate the model, but again this yielded nonsensical results (a NAIRU series that is negative for all periods!).

I don't see how the general form of the model (which closely follows the "triangle" approach of Gordon (1997)) or the data I've used (standard BLS and BEA series) could possibly produce these bizarre results, so it seems like I must be doing something wrong in specifying the model in EViews.

At this point, it is difficult to pinpoint the problem (if any) without seeing your workfile that contains the data.

Here us the workfile. It includes the data series I've been using, as well as various models I've estimated.

I can assure you that the problem is definitely not related to EViews. Actually, there is not any "real" problem going here. If you read Gordon (1997) carefully, you will see that the estimated models are nothing similar to that of your's. In the original article, estimated models contain lots of data massaging and restrictive assumptions, each of which can have significant impact on the results. State Space models are very flexible and therefore can be quite sensitive to such type of manipulations. Sometimes, even a different sample period can lead to a quite different estimation output. Putting the model into a state space form is one thing, but ensuring the validity and robustness of results is quite another. So, you can do nothing but continue to try different specifications...