Using add-factors as exogenous variables?

[tvonbrasch]

Hi

We have a model where a block looks something like this

Code: Select all

y=f(y,x)+y_a x=g(y,x)+x_a

Ideally, we would like to link the add-factor in the second equation with the first equation, i.e.

Code: Select all

d(y_a)=d(x_a).

to provide some intuition, let y be market prices and x be basic prices. it would be convenient if a change to basic prices from using an add-factor is automatically also applied to market prices. however, endogenizing an add-factor is not allowed in the model object, if I have understood it correctly. I tried to make another model:

Code: Select all

y=f(y,x)+y_b+y_a x=g(y,x)+x_a d(y_b)=d(x_a) ,

but this specification was not allowed either. I do not want to make the model (Model C):

Code: Select all

y=f(y,x)+y_b+y_a x=g(y,x)+x_b+x_a d(y_b)=d(x_b)

since, I suspect that the users of our model will forget to use the auxiliary add-factor x_b instead of x_a when adjusting the add-factor. Any change to x from using x_a will thus not also impact y_a.

Is there some way to link the add-factor in one equation to another variable in another equation in the model? One way that could work with a model looking like Model C would be if the SETBOUNDS command could be used on exogenous variables. That way, the user could be warned if she tried to change the add-factor x_a instead of the auxiliary exogenous variable x_b. Can you add the possibility of creating warnings also for exogenous variables? Or is there another smart way of dealing with this issue?
Thomas

[EViews Matt]

Hi Thomas,

I agree that effectively having two sets of add factors per equation is cumbersome and error-prone. Working within the current limits of EViews' model object, I see two options for setting up the model as you desire. Both place an extra burden on the end-user, you can judge if the burden is too heavy...

First, from a model object's point of view, an add factor is an extremely limited type of exogenous variable. Most relevant is that an add factor is present only implicitly in the model, i.e., you cannot explicitly refer to the add factor in any way, as you discovered. Consequently, if you wish to relate two add factors, then that relationship must be enforced outside the model object. If the model is being solved from within an EViews program, it's easy to add this as a preprocessing step, e.g.,

Code: Select all

series d(y_a) = d(x_a) themodel.solve

Some care may need to be taken with regard to samples.

Alternatively, if you'd rather enforce the relationship within the model, then those variables cannot be add factors. As normal endogenous and exogenous variables (playing the role of add factors), the extra hassle comes in altering the model specification and initializing the variables. Either way, you can continue to use the familiar *_a naming convention associated with add factors, which should make things easier for the user.

[tvonbrasch]

Hi Matt

thanks for your swift reply. you provide two okay solutions. regarding your second alternative. you state that I can use a variable called y_a as an exogenous variable, i.e. using the standard naming convention for add-factors. Would it be possible to use the variable name y_b for an add-factor? I need to have an add-factor in that equation also so as to initialise the model properly using the addinit command. if i can rename an add-factor to y_b then my problem is basically solved.

thanks again
Thomas

[EViews Matt]

Hello,

It is possible by modifying the model's text specification. The command that specifies the presence of an add factor in an equation, e.g.,

Code: Select all

@ADD Y Y_A

will accept non-"_A" names for the add factor series, e.g.,

Code: Select all

@ADD Y Y_B

After a few quick tests, this doesn't appear to break anything, but no guarantees.

[tvonbrasch]

You are the man Matt!

Great, thanks. I will try this solution
Thomas