On Wed, 9 May 2018, Sven Schreiber wrote:
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?
I agree that the irf() function is a singleton: it's a cross between
an accessor and a regular function. It differs from $-accessors in
that they take no arguments, and from regular functions in that it
requires an "implicit argument" based on internal program state.
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.
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.
Allin