Menu
▾
▴
#204 new ways to formulate SVAR restrictions
Since "SVAR" is an addon, I'm creating a regular feature request ticket even though it's not about core gretl...
Taking this here from the mailing list, there were two ideas that seemed feasible.
- Extend the SVAR_restrict function to take the full restriction pattern matrix as an argument. Use the new "numeric" arg type for that to overload the 3rd (?) arg of that function.
- In the traditional one-by-one way of specifying point restrictions (e.g., zero restrictions on the C matrix), make it possible to specify the structural shock as well as the target variable not only by index position (this is the status quo), but also by using their assigned names, similar to what is possible in the context of set ID restrictions.
I wonder if it could be possible to use external files to enforce identification schemes: I'm taking the example of Matlab BEAR, here the user can provide zero-sign restrictions via Excel tables. Maybe is it possible to do a similar thing in gretl? Maybe with .csv or .txt files?
Well, gretl's mread() function also supports .csv files. For example, the attached matrix file which defines a Choleski-style triangular restriction is read fine by mread. So if that's what you mean, the new-style SVAR_restrict function would also allow such input.
Or do you mean that the path string to the file should be provided as an argument? Then we'd have a problem with the arg type of the function, or at least we would have to think about it.
I mean the second alternative, that is the whole file path: in this way, it could be possible to specify various kind of restrictions not limited to numerical ones. For example, suppose to have a .csv like the following one:
+,+
-, +
or something like
+, +
-, 0
these will reproduce sign or mixed restrictions.
I know that this will imply major changes with the functions but maybe it 's worth thinking about it since flexibility would be improved (I hope so XD).
Interesting idea, and introducing a new function for stuff like that wouldn't be too bad, I guess. (Of course reading such files would require a separate parsing function, but would be feasible.)
However, how would you specify restrictions beyond the immediate impact effect? Sign (and bounds) restrictions are usually given for a range of horizons. What does BEAR (or others) do in that case?
Good question! I'll investigate and let you know!
Hi @lucapedini , did you have a chance to check what BEAR does in the meantime? thanks.
Sorry, I didn't ...I'll have a look in the next week. As a matter of fact, I'll probably work with a colleague of mine who uses BEAR, so I can ask him too.
Sorry for being always late in replying. In BEAR you can pass your model as an Excel file, where in each sheet some information are provided such as data, type of BVAR to use, parameter priors and so on. As concerns restrictions, you can use two additional sheets, in the former there are the zero or sign restrictions placed inside a k x k table, where k is the # of variables. The latter should have the same structure with the same table, where instead of having restrictions it has the length.
Thanks, @lucapedini. So if I understand correctly and you can "only" specify a length, then the start of the (sign) restriction is always on impact?
One more question: I guess when you have an unrestricted element, then you just leave the corresponding table cell empty?
Sorry, I wasn't so precise in saying "length": as a matter of fact you have to specify two integers separated by a space where the first entry being the starting period and the second one the final period. As for your second question, yes, an empty cell means no restrictions.
OK, the pattern restriction matrix approach and the string names are now implemented in 2024c, and so I'm closing this.
(There was some discussion about external tabular-like files like in BEAR, but we can/should continue that discussion elsewhere.)