3:57 p.m.
Hi,
consider this example:
<hansl>
open denmark
var 2 LRM LRY -q # printout says "lag order 2"
eval $system.order # gives 2
vecm 2 1 LRM LRY -q # again, printout says "lag order 2"
eval $system.order # gives 1
</hansl>
Of course all this is just a matter of convention, but since "vecm"
expects the lag order parameter as referring to the levels (thus the
same as the corresponding VAR), and the printout also refers to that
levels order, I tend to view this as a bug. Right?
thanks
sven
4 p.m.
Am 24.02.2022 um 16:57 schrieb Sven Schreiber:
vecm 2 1 LRM LRY -q # again, printout says "lag order 2"
eval $system.order # gives 1
</hansl>
Of course all this is just a matter of convention, but since "vecm"
expects the lag order parameter as referring to the levels (thus the
same as the corresponding VAR), and the printout also refers to that
levels order, I tend to view this as a bug. Right?
OK, so in lib/src/var.c in the johansen_wrapper function we have the
root cause:
jvar = gretl_VAR_new(code, order - 1, rank, lags, list, dset, ...
However, that difference-order convention for VECMs is used in so many
subsequent and other places that we cannot simply change that there.
Note that this leads to funny re-incrementing hoops like the call to
johansen_wrapper inside real_gretl_restricted_vecm where the lag order
is specified as orig->order + 1.
At the same time, in lots of places in the code there are constructs
like calling effective_order or "int k = var->order + (var->ci ==
VECM);" to map the whole thing back to the levels convention. What's
more, in build_VAR_from_bundle the var->order is taken as-is from the
bundle, irrespective of whether it's a VECM or a VAR.
So, basically it seems that gretl uses the difference-order convention
for a VECM _internally_, but _externally_ we have the levels-order
convention. The problem is that "$system.order" exists both in the
internal and external spheres: internal because of how hansl's irf() and
fevd() functions are currently set up, and external for users like me
who want to work with the $system output.
How can we solve that? Not entirely sure, but perhaps we could change
the backends of irf() and fevd(), namely gretl_FEVD_from_bundle and
gretl_IRF_from_bundle to differentiate between a VAR and a VECM
appropriately, and then we could make $system.order adhere to the
external levels-order convention. (You couldn't transfer the produced
$system bundles across gretl versions, but that's not a showstopper
IMHO, because who does that anyway.)
What do you think?
thanks
sven
5:15 p.m.
Am 25.02.2022 um 17:00 schrieb Sven Schreiber:
So, basically it seems that gretl uses the difference-order convention
for a VECM _internally_, but _externally_ we have the levels-order
convention. The problem is that "$system.order" exists both in the
internal and external spheres: internal because of how hansl's irf() and
fevd() functions are currently set up, and external for users like me
who want to work with the $system output.
How can we solve that? Not entirely sure, but perhaps we could change
the backends of irf() and fevd(), namely gretl_FEVD_from_bundle and
gretl_IRF_from_bundle to differentiate between a VAR and a VECM
appropriately, and then we could make $system.order adhere to the
external levels-order convention. (
Another option might be to simply document $system.order in the VECM
case better, and perhaps also add a new $system.levelsorder element
which would equal $system.order + 1 (in the vecm case).
Below is my current state of a hansl function which retrieves the levels
lag order from $system in the various cases. Currently we don't have
$system.order for a "system" in the narrow sense (non-var, non-vecm),
maybe we should add that as well.
thanks
sven
---
<hansl>
function scalar getorder(const bundle sys)
if sys.command == "system"
# infer the endogenous lag order from the sysA shape
order = cols(sys.A) / sys.neqns
elif sys.command == "var" || sys.command == "vecm"
if sys.command == "var"
order = sys.order
elif sys.command == "vecm"
order = sys.order + 1
# (at least up to gretl 2022a the vecm $system.order
# refers to the differences)
endif
else
funcerr "input doesn't seem to be a $system bundle"
endif
return order
end function
</hansl>
1054
days inactive
1061
days old
2 comments
1 participants
participants (1)
-
Sven Schreiber