12:51 p.m.
Here's an update in relation to the thread (re-)started by Sven at
http://lists.wfu.edu/pipermail/gretl-devel/2018-May/008776.html .
We now have irf() and fevd() functions which go part-way to meeting
Sven's suggestions. We could go all the way if we reckon it's
worthwhile (see below). Anyway, at present:
irf() function:
arg1 target [required]
arg2 shock [required]
arg3 alpha [optional]
arg4 bundle [optional, obtain via $system]
Returns: matrix containing response of targ to shock, optionally
with bootstrap confidence interval.
fevd() function:
arg1 target [required]
arg2 bundle [optional, obtain via $system]
Returns: matrix containing full decomposition of forecast variance
of targ.
The final, optional, bundle argument should be obtained via the
$system accessor (which still has to be documented) after estimation
of a VAR or VECM. If this argument is omitted gretl looks to the
last estimated model to get the equivalent information; if there's
no such model or it's not a VAR/VECM an error is flagged.
The divergence from Sven's specific suggestions reflects some
(debatable) simplification on my part.
It seems to me that when a FEVD is wanted, most of the time you'd
want it for a single "target" variable and all sources of variation.
So right now you must choose a target and do not get to choose a
single source. You can of course pull a specific column of interest
out of the returned matrix if you want less information, or call the
function in a loop if you want more.
In the (more expensive) IRF case, however, it seems to me that the
response of a single target to a single shock (with or without a
confidence interval) would be the most "natural" unit. So you have
to specify both target and shock.
Possible modifications: We could add a "source" argument to fevd()
to narrow the output, and for the target/shock arguments to both
functions we could let 0 signify "do everything".
Allin
5:10 a.m.
Am 22.05.2018 um 18:51 schrieb Allin Cottrell:
We now have irf() and fevd() functions which go part-way to meeting
Sven's suggestions. We could go all the way if we reckon it's
worthwhile (see below). Anyway, at present:
That's a very welcome addition, thanks! (Although I had to remind myself
it's all about the built-in Choleski identification.)
Is the horizon for these functions determined by the "set" command or is
it taken from the $system bundle?
The final, optional, bundle argument should be obtained via the
$system accessor
I think that it's very good that the functions can be used
"standalone"
now, without requiring an implicit context.
It seems to me that when a FEVD is wanted, most of the time you'd
want
it for a single "target" variable and all sources of variation.
Not sure
that's correct. Sometimes a new type of shock is proposed and
then the question is "how much of output does it explain? and of
consumption?" and so forth.
BTW, I'm not necessarily pushing that feature, but in principle fevd()
could also get a bootstrap variant like irf() has. It's certainly less
common to see assessments of fevd fraction uncertainty compared to irf
bands, but it would just be a mirror image.
(Am I right in assuming that a new alpha argument could be added in the
future without compromising backwards compatibility? What I mean is that
a call like fevd(<int>, <bundle>) would still be possible if the in the
future the signature would be: <int>, <optional-scalar>, <bundle>,
right?)
In the (more expensive) IRF case, however, it seems to me that the
response of a single target to a single shock (with or without a
confidence interval) would be the most "natural" unit. So you have to
specify both target and shock.
Yes, that's the way it is done now. But I've
asked myself in the past
what happens in the bootstrap case; if you call irf() in a loop to get
all responses and you want the bootstrap, it seems a bootstrap has to be
done N times instead of just once. (Or even N^2 times.)
Possible modifications: We could add a "source" argument to fevd() to
narrow the output, and for the target/shock arguments to both
functions we could let 0 signify "do everything".
The argument in favor of source in fevd is mainly the analogy to irf I'd
say. The "do everything" variant can always come later without breaking
anything; however, it would seem to be much more efficient in the
bootstrap case.
thanks,
sven
1:45 p.m.
On Wed, 23 May 2018, Sven Schreiber wrote:
Am 22.05.2018 um 18:51 schrieb Allin Cottrell:
>
> We now have irf() and fevd() functions which go part-way to meeting Sven's
> suggestions. We could go all the way if we reckon it's worthwhile (see
> below). Anyway, at present:
That's a very welcome addition, thanks! (Although I had to remind myself it's
all about the built-in Choleski identification.)
Is the horizon for these functions determined by the "set" command or is it
taken from the $system bundle?
As things stand the horizon is taken from "set". We could insert an
argument to determine it.
> The final, optional, bundle argument should be obtained via the
$system
> accessor
I think that it's very good that the functions can be used "standalone"
now,
without requiring an implicit context.
Agreed.
> It seems to me that when a FEVD is wanted, most of the time
you'd want it
> for a single "target" variable and all sources of variation.
Not sure that's correct. Sometimes a new type of shock is proposed and then
the question is "how much of output does it explain? and of consumption?" and
so forth.
OK, I take that point. So I think we do want a "source" or "shock"
argument to fevd().
BTW, I'm not necessarily pushing that feature, but in principle
fevd() could
also get a bootstrap variant like irf() has. It's certainly less common to
see assessments of fevd fraction uncertainty compared to irf bands, but it
would just be a mirror image.
OK, "for future reference" ;-)
(Am I right in assuming that a new alpha argument could be added in
the
future without compromising backwards compatibility? What I mean is that a
call like fevd(<int>, <bundle>) would still be possible if the in the future
the signature would be: <int>, <optional-scalar>, <bundle>, right?)
Hmm, not really. You'd need an argument-separating comma, as in
fevd(<int>,,<bundle>)
It's true that since the (notional) second and third arguments here
are of different types, we could in principle check the types and
"see" that the argument given second must really be the third one,
but that sort of thing (auto-detection of implicitly omitted
optional arguments) is not supported in geneval.c for any functions
at present. Its also strikes me as kinda tricksy.
> In the (more expensive) IRF case, however, it seems to me that
the response
> of a single target to a single shock (with or without a confidence
> interval) would be the most "natural" unit. So you have to specify both
> target and shock.
Yes, that's the way it is done now. But I've asked myself in the past what
happens in the bootstrap case; if you call irf() in a loop to get all
responses and you want the bootstrap, it seems a bootstrap has to be done N
times instead of just once. (Or even N^2 times.)
>
> Possible modifications: We could add a "source" argument to fevd() to
> narrow the output, and for the target/shock arguments to both functions we
> could let 0 signify "do everything".
>
The argument in favor of source in fevd is mainly the analogy to irf I'd say.
The "do everything" variant can always come later without breaking anything;
however, it would seem to be much more efficient in the bootstrap case.
I take the IRF efficiency point. And Yes, supporting "0 means all"
is something that could easily be added later without breaking
backward compatibility.
Allin
10:32 a.m.
New subject: optional arguments (was Re: irf() and fevd())
Am 23.05.2018 um 19:45 schrieb Allin Cottrell:
On Wed, 23 May 2018, Sven Schreiber wrote:
> (Am I right in assuming that a new alpha argument could be added in
> the future without compromising backwards compatibility? What I mean
> is that a call like fevd(<int>, <bundle>) would still be possible if
> the in the future the signature would be: <int>, <optional-scalar>,
> <bundle>, right?)
Hmm, not really. You'd need an argument-separating comma, as in
fevd(<int>,,<bundle>)
It's true that since the (notional) second and third arguments here
are of different types, we could in principle check the types and
"see" that the argument given second must really be the third one, but
that sort of thing (auto-detection of implicitly omitted optional
arguments) is not supported in geneval.c for any functions at present.
Its also strikes me as kinda tricksy.
I found the part of the doc that inspired my hunch, it was in the
strsplit help:
<help-quote>
strings S = strsplit(basket,,",")
will split the input into an array of four strings using comma as
separator. The “extra” comma in the input above indicates that the i
argument is omitted, but it's not strictly necessary unless you wish to
extract a single element; if the second argument is a string and only
two arguments are given it is understood that sep rather than i is
intended. So
strings S = strsplit(basket, ",")
...
</help-quote>
So this only works in this particular function, not in general?
thanks,
sven
9:11 p.m.
New subject: optional arguments (was Re: irf() and fevd())
On Sun, 27 May 2018, Sven Schreiber wrote:
Am 23.05.2018 um 19:45 schrieb Allin Cottrell:
> On Wed, 23 May 2018, Sven Schreiber wrote:
>
>> (Am I right in assuming that a new alpha argument could be added in
>> the future without compromising backwards compatibility? What I mean
>> is that a call like fevd(<int>, <bundle>) would still be possible if
>> the in the future the signature would be: <int>, <optional-scalar>,
>> <bundle>, right?)
>
> Hmm, not really. You'd need an argument-separating comma, as in
>
> fevd(<int>,,<bundle>)
>
> It's true that since the (notional) second and third arguments here
> are of different types, we could in principle check the types and
> "see" that the argument given second must really be the third one, but
> that sort of thing (auto-detection of implicitly omitted optional
> arguments) is not supported in geneval.c for any functions at present.
> Its also strikes me as kinda tricksy.
I found the part of the doc that inspired my hunch, it was in the
strsplit help:
<help-quote>
strings S = strsplit(basket,,",")
will split the input into an array of four strings using comma as
separator. The “extra” comma in the input above indicates that the i
argument is omitted, but it's not strictly necessary unless you wish to
extract a single element; if the second argument is a string and only
two arguments are given it is understood that sep rather than i is
intended. So
strings S = strsplit(basket, ",")
...
</help-quote>
So this only works in this particular function, not in general?
OMG, you're right but that now seems a bad precedent! So far as I
can see there's no way this can work "in general" without
hand-coding the argument-handling for every function to which this
special dispensation might be applicable.
I need to think some more about this. _Maybe_ there's a viable
mode of generalization.
Allin
1:50 a.m.
New subject: optional arguments (was Re: irf() and fevd())
Am 28.05.2018 um 03:11 schrieb Allin Cottrell:
I need to think some more about this. _Maybe_ there's a viable mode of
generalization.
If not, then I'd be in favor of removing it (or un-document it) in
strsplit, even though it's nice there. But it hasn't been around for long.
cheers,
sven
9:47 a.m.
New subject: optional arguments (was Re: irf() and fevd())
On Mon, 28 May 2018, Sven Schreiber wrote:
Am 28.05.2018 um 03:11 schrieb Allin Cottrell:
>
> I need to think some more about this. _Maybe_ there's a viable mode of
> generalization.
>
If not, then I'd be in favor of removing it (or un-document it) in strsplit,
even though it's nice there. But it hasn't been around for long.
Agreed!
I've begun to think about the generalization question and I can sort
of see a mechanism that could do the job, but implementing it would
be a substantial piece of work. Definitely not something to embark
upon with a release imminent. Maybe the best plan for now is to
remove the claim in the strsplit doc and revisit the point later.
Allin
9:57 a.m.
New subject: optional arguments (was Re: irf() and fevd())
Am 28.05.2018 um 15:47 schrieb Allin Cottrell:
On Mon, 28 May 2018, Sven Schreiber wrote:
> Am 28.05.2018 um 03:11 schrieb Allin Cottrell:
>>
>> I need to think some more about this. _Maybe_ there's a viable mode
>> of generalization.
>>
> If not, then I'd be in favor of removing it (or un-document it) in
> strsplit, even though it's nice there. But it hasn't been around for
> long.
Agreed!
I've begun to think about the generalization question and I can sort
of see a mechanism that could do the job, but implementing it would be
a substantial piece of work. Definitely not something to embark upon
with a release imminent. Maybe the best plan for now is to remove the
claim in the strsplit doc and revisit the point later.
I think so, too. Not being explicit about argument defaults in the
middle was already a nice step forward for hansl. Removing the extra
commas would be another workaround for the lack of non-positional
arguments, but in the end it would also be a workaround. In the medium
term at least I believe the status quo is perfectly fine. I tend to
think that if there is ever going to be a substantial generalization,
the aim should be keyword arguments as in other languages. But again, if
ever.
thanks,
sven
10:45 a.m.
Am 23.05.2018 um 19:45 schrieb Allin Cottrell:
On Wed, 23 May 2018, Sven Schreiber wrote:
> Am 22.05.2018 um 18:51 schrieb Allin Cottrell:
>>
>> We now have irf() and fevd() functions which go part-way to meeting
>> Sven's suggestions. We could go all the way if we reckon it's
>> worthwhile (see below). Anyway, at present:
OK, I take that point. So I think we do want a "source" or
"shock"
argument to fevd().
> The argument in favor of source in fevd is mainly the analogy to
irf
> I'd say. The "do everything" variant can always come later without
> breaking anything; however, it would seem to be much more efficient in
> the bootstrap case.
I take the IRF efficiency point. And Yes, supporting "0 means all" is
something that could easily be added later without breaking backward
compatibility.
Not sure whether we were still in the middle of a discussion here. At
least in the latest snapshot the new behavior of the functions isn't
documented yet.
cheers,
sven
5:41 p.m.
On Tue, 5 Jun 2018, Sven Schreiber wrote:
Am 23.05.2018 um 19:45 schrieb Allin Cottrell:
> On Wed, 23 May 2018, Sven Schreiber wrote:
>
>> Am 22.05.2018 um 18:51 schrieb Allin Cottrell:
>>>
>>> We now have irf() and fevd() functions which go part-way to meeting
>>> Sven's suggestions. We could go all the way if we reckon it's
worthwhile
>>> (see below). Anyway, at present:
> OK, I take that point. So I think we do want a "source" or
"shock" argument
> to fevd().
>> The argument in favor of source in fevd is mainly the analogy to irf I'd
>> say. The "do everything" variant can always come later without breaking
>> anything; however, it would seem to be much more efficient in the
>> bootstrap case.
>
> I take the IRF efficiency point. And Yes, supporting "0 means all" is
> something that could easily be added later without breaking backward
> compatibility.
Not sure whether we were still in the middle of a discussion here. At least
in the latest snapshot the new behavior of the functions isn't documented
yet.
I'll try to get this documented shortly. My plan at present is to make
fevd() into a three-argument function: target, shock, and (optional)
VAR ($system) bundle.
In the first instance (i.e. 2018b release) the second argument may end
up as a placeholder for future functionality (if not added by release
time, then to be added not too long thereafter). I'm reluctant to add
a placeholder "alpha" argument after "shock" because I seriously doubt
that bootstrapping of the FEVD is something we're likely to add any
time soon.
Allin
6:49 a.m.
On Fri, 8 Jun 2018, Allin Cottrell wrote:
On Tue, 5 Jun 2018, Sven Schreiber wrote:
> Am 23.05.2018 um 19:45 schrieb Allin Cottrell:
>> On Wed, 23 May 2018, Sven Schreiber wrote:
>>
>>> Am 22.05.2018 um 18:51 schrieb Allin Cottrell:
>>>>
>>>> We now have irf() and fevd() functions which go part-way to meeting
>>>> Sven's suggestions. We could go all the way if we reckon it's
worthwhile
>>>> (see below). Anyway, at present:
>
>> OK, I take that point. So I think we do want a "source" or
"shock"
>> argument to fevd().
>
>>> The argument in favor of source in fevd is mainly the analogy to irf I'd
>>> say. The "do everything" variant can always come later without
breaking
>>> anything; however, it would seem to be much more efficient in the
>>> bootstrap case.
>>
>> I take the IRF efficiency point. And Yes, supporting "0 means all" is
>> something that could easily be added later without breaking backward
>> compatibility.
>
> Not sure whether we were still in the middle of a discussion here. At least
> in the latest snapshot the new behavior of the functions isn't documented
> yet.
I'll try to get this documented shortly. My plan at present is to make
fevd() into a three-argument function: target, shock, and (optional) VAR
($system) bundle.
In the first instance (i.e. 2018b release) the second argument may end up as
a placeholder for future functionality (if not added by release time, then to
be added not too long thereafter). I'm reluctant to add a placeholder
"alpha"
argument after "shock" because I seriously doubt that bootstrapping of the
FEVD is something we're likely to add any time soon.
Update: there's now documentation in git. And the second argument to
fevd() is not a dummy, it's properly enabled (with 0 meaning "all").
Allin
11:56 a.m.
Am 10.06.2018 um 12:49 schrieb Allin Cottrell:
On Fri, 8 Jun 2018, Allin Cottrell wrote:
> I'll try to get this documented shortly. My plan at present is to make
> fevd() into a three-argument function: target, shock, and (optional)
> VAR ($system) bundle.
>
> In the first instance (i.e. 2018b release) the second argument may
> end up as a placeholder for future functionality (if not added by
> release time, then to be added not too long thereafter). I'm
> reluctant to add a placeholder "alpha" argument after "shock"
because
> I seriously doubt that bootstrapping of the FEVD is something we're
> likely to add any time soon.
Update: there's now documentation in git. And the second argument to
fevd() is not a dummy, it's properly enabled (with 0 meaning "all").
Great, looks very nice and understandable!
thanks,
sven
2352
days inactive
2371
days old
11 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber