the function reference says that after restricting the alphas in a VECM
you don't get $xtxinv, and I can see the reason why (I think).
However, this seems to work:
vecm 4 1 LRM LRY IBO
a = 0
b = 1
end restrict --full
Bug or feature?
Am 23.08.20 um 01:43 schrieb Allin Cottrell:
> On Sat, 22 Aug 2020, Sven Schreiber wrote:
>> Am 18.08.2020 um 16:19 schrieb Artur Tarassow:
>>> I spotted a possible "bug" when trying to plot weekly or hourly data
>>> over time. Take a time-series, set some frequency and check the plot.
>>> Even though the <print invest -o> command shows a correct date index,
>>> the x-axis of the plot does _not_ show any date format for weekly or
>>> hourly data. For other frequencies, things are fine.
>> I agree it would be nice to also display that information in the graphs.
> Well-tested patches would be reviewed with interest. Otherwise, I'm
> afraid this is not a priority for me.
[moving this to devel]
This is perfectly fine, we know you are constantly working hard on many
aspects of gretl.
I have started experimenting with the sample label printing business in
the branch "samplelabel" branch on git. Certainly very far from being
well tested (actually already with a known bug where I haven't pushed
the fix yet, but will in a minute). This is not exactly the same thing
as date label printing in plots, but similar I think.
When looking at the code, I see the function 'ntodate' (in
lib/src/dataio.c) which nowadays is a little misleading I'd say, because
it is also used to construct the label for a panel observation (which
includes the unit, not just a date). So my proposal would be to adjust
that name eventually - of course this means a lot of changes to all the
calls, but with grep and search and replace this shouldn't be a big
problem. Or is there anything I'm missing?
And a question: AFAICS dset->panel_pd is the time-series frequency
within a panel dataset. (So playing the role of dset->pd in a
time-series dataset, but dset->pd is the overall time dimension length
in the panel context, cf. also the hansl accessor $pd -- I've always
found that confusing! So what actually is the hansl way to retrieve the
information about the time series frequency in a panel, after it has
been set with --set-panel-time??) My question: does this panel_pd always
exist in a panel, or only conditionally on the user action of setting it?
Hi especially Claudia and Jack,
HIP's code uses the exists() function which was introduced in gretl
2016a. Currently (0.5) it specifies gretl 1.10.0 instead. Please update
I would also suggest to increase the version number to 1.0, given that
no bugs have been reported as far as I am aware. Or if you think there's
some urgently missing functionality, it would be good to mention it in
the help file I think. (Maybe it is already the case?)
I was thinking that there are quite a few things we should make a decision
on for the next version. One is exposing our time disaggregation apparatus
(currently hidden as the _tdisagg()) function. Another one is finally
getting rid of tha arbond command.
On a more general level, now that Allin has implemented elastic nets too,
should we have a "machine learning tools" submenu somewhere, with SVM,
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
I was updating the translations of the Portuguese files, and I noticed some
missing translations on the Italian files, so I am sharing my process
because it may be helpful to you too.
Analysis of missing translations.
Example for Italian (commands on Linux):
1 - cd doc/commands
2 - grep "function name=" gretl_functions_en.xml >list_en_.txt
3 - grep "function name=" gretl_functions_it.xml >list_it_.txt
4 - # Optionally count the lines of functions
- wc -l list_en_.txt list_it_.txt
5 - # See what are the differences on functions lists (I use meld from
meldmerge.org) you can install with system commands, like "dnf install meld"
- meld list_en_.txt list_it_.txt &
6 - # Optionally use meld to do the editing
- meld gretl_functions_en.xml gretl_functions_it.xml &
# We can search for a missing translation like:
A better way to see differences, includes different arguments:
diff --left-column --suppress-common-lines list_en_.txt list_it_.txt
< <function name="$mapfile" section="access" output="string">
< <function name="$pkgdir" section="access" output="string">
< <function name="$seed" section="access" output="scalar">
< <function name="geoplot" section="data-utils" output="none">
< <function name="I" section="matbuild" output="matrix">
> <function name="I" section="matbuild" output="smatrix">
< <function name="mlag" section="transforms" output="matrix">
> <function name="mlag" section="stats" output="matrix">
< <function name="mread" section="data-utils" output="matrix">
> <function name="mread" section="matbuild" output="matrix">
< <function name="stack" section="data-utils" output="series">
< <function name="strftime" section="calendar" output="string">
> <function name="strftime" section="strings" output="string">
sorry, another thread about forecasts: I'm a bit surprised that the
significance level is not user-settable in the GUI options window after
asking for forecasts (in the VAR context). It seems to be fixed at 95%.
This is different from the interface for single equations, where alpha
can be chosen.
Should I create a feature request ticket?
I'm currently reviewing and amending the documentation for forecasts in
the guide. One thing I wasn't aware of before is that apparently it
isn't possible to produce a forecast plot for a single variable in a
VAR. What I mean is something like this:
smpl +0 -4
var 2 LRY LRM --silent
fcast LRY --out-of-sample --plot=check.pdf # not supported
I don't really understand why this cannot be done, apart from historical
path-dependent reasons. Note that I'm specifying a single variable from
the VAR, so I'm only asking for a simple plot like in a single equation.
The forecast results themselves are of course also there in gretl,
because without the --plot option it works fine (as it should).
AFAICS there is currently no way to produce a forecast plot from a VAR
with a script, or am I missing something? (And I don't mean to reinvent
the wheel by using the $fcast results "manually".)
It would be very useful if this gap could be filled. Then for example we
could also use a loop to put the results into the "multiplot" package.
in the context of forecasting there's on line 1977 of gui/library.c the
There are no observations available for forecasting\n"
"out of sample. If you wish, you can add observations\n"
"(Data menu, Edit data), or you can shorten the sample...
Shouldn't it be instead: Data menu, Add observations?