Am 15.05.2018 um 22:53 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. See below on the irf/fevd relationship. >>>> Alternatively, the irf() function could get a new bundle argument >>>> which would collect the VAR/VECM results. > Backward compatibility, of course, requires that however we modify > irf(), it should continue to work as before. I can see adding an > optional final argument, probably in the form of a $system bundle as can > now be retrieved after estimation of a VAR or VECM, but I think that > should await stabilization and documentation of $system, which right now > is in an experimental state. This sounds very reasonable. > 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). cheers, sven
