Hi, the irf() function is a weird thing in the sense that it is the only (?) function that requires input beyond its specified arguments. Namely the information from the previous VAR/VECM estimation. From a programming-language systematic point of view it seems to be the "odd man out". In contrast, the analogous FEVD calculations are not wrapped in a function, but in the $fevd accessor, which makes more sense IMO. So I suggest to introduce a matching $irf accessor with the same layout as the $fevd accessor. I am aware that the irf() function also needs an alpha input; this could be done via "set irf_alpha 0.1" or something like that. Alternatively, the irf() function could get a new bundle argument which would collect the VAR/VECM results. That way, no dependency on non-argument input would be required, making the use consistent with all other functions.

Am 11.04.2018 um 14:16 schrieb Allin Cottrell: > On Tue, 10 Apr 2018, Sven Schreiber wrote: >> So I suggest to introduce a matching $irf accessor with the same layout as >> the $fevd accessor. I am aware that the irf() function also needs an alpha >> input; this could be done via "set irf_alpha 0.1" or something like that. >> >> Alternatively, the irf() function could get a new bundle argument which >> would collect the VAR/VECM results. That way, no dependency on >> non-argument input would be required, making the use consistent with all >> other functions. > > Point taken. But right now I'm busy working on ARMA and I don't want to get > distracted. Could you maybe file a bug report or feature request so this > doesn't get forgotten? This became feature request #110 a while ago. Since the ARMA stuff seems to be settled now, any chance to discuss the possible solution for this thing further?

Am 15.05.2018 um 22:53 schrieb Allin Cottrell: > Personally, I don't see much point in adding an $irf accessor (which would > then require adding more "libset" variables); it seems to me this would > just offer a less convenient way of doing what irf() can do at present. In terms of functionality, yes. But I find that things are much easier to learn, to teach, and to remember when they are consistent. So if getting $irf is too complicated and we can't have a $irf/$fevd pair, then I would suggest the other route and introduce an analogous fevd() function to have a matching irf() and fevd() pair. The args for fevd() would be: - integer target (like irf), default 0 (meaning all) - integer shock (like irf), default 0 (meaning all) - bundle $system lookalike, as in the future irf(), default null A plain call without explicit arguments would then be equivalent to the current $fevd (which would remain in place).