Wrong syntax highlighting
by Marcin Błażejowski
Hi,
simple script:
<hansl>
a = 5.4
b = int(a)
</hansl>
Here 'int' should be highlighted as a function not gretl-type.
Marcin
--
Marcin Błażejowski
2 years, 10 months
- 1
- 0
Building and installing addons
by Johannes Lips
Hi all,
when trying to replicate the issue Sven faced in another thread. I came
across the issue that currently the shipped addons are not built and
installed in fedora.
I am using the gretl spec file, which can be found at [1].
I tried adding
%configure --disable-static \
--disable-avx \
--with-mpi \
--with-dbnomics \
--with-extra \
--with-geoplot \
--with-gig \
--with-ivpanel \
--with-SVAR
the addons to the configure command, but no luck. Could you please tell
me how to build and install these addons?
Thanks
Johannes
[1] https://src.fedoraproject.org/rpms/gretl/blob/rawhide/f/gretl.spec
2 years, 10 months
- 5
- 10
seasonal adjustment: gretl + X13 compared with JDemetra(+)
by Sven Schreiber
Hi everybody,
let me open a new thread with an informative title although in principle
this could be seen as a continuation of the previous one named "basic
questions/comments on X13".
(But first of all let me repeat the question, is there a special reason
why plugin/tramo_x12.h is written with
an underscore but plugin/tramo-x12.c with a hyphen?)
OK, so now in gretl 2022a we can choose quite detailed options through
the bundle argument of the deseas() function (X13 only so far, not
Tramo). Time to go back to the original motivation and compare results
with JDemetra again. (When I write JDemetra I basically mean JDemetra+,
don't know what the plus there is supposed to mean.)
The pre-defined options collections RSA0-RSA5c can be found for example
in this document:
https://cran.r-project.org/web/packages/RJDemetra/RJDemetra.pdf, p. 72.
Here's my updated status quo of how to (try to) mimic those basic
settings with gretl's deseas() function:
<hansl>
# The following options are still experimental,
# i.e. whether they actually constitute what they should is
# still not known 100%.
# (outliers=7 in gretl 2022a means all, i.e. AO/LS/TC, see also the
deseas function reference)
bundle RSA0_opts = _(logtrans=0, outliers=0, trading_days=0, airline=TRUE)
bundle RSA1_opts = _(logtrans=2, outliers=7, trading_days=0, airline=TRUE)
bundle RSA2c_opts = _(logtrans=2, outliers=7, working_days=2,
easter=TRUE, airline=TRUE)
bundle RSA3_opts = _(logtrans=2, outliers=7, trading_days=0)
bundle RSA4c_opts = _(logtrans=2, outliers=7, working_days=2, easter=TRUE)
bundle RSA5c_opts = _(logtrans=2, outliers=7, trading_days=2, easter=TRUE)
</hansl>
For comparison I'm using the results of the main example series that
comes with the RJdemetra wrapper package for R. (A colleague was so kind
to run those for me.) That monthly series spans the range 1990-2020, I
believe it's industrial production growth in France or so. What I'm
getting is:
- RSA0: identical up to numerical noise (on the order of 1e-6 %)
- RSA1: basically the same (max order 1.5e-4 %)
- RSA2c: ditto
- RSA3: Noticeable deviations with a visual seasonal pattern, only at
/peaking around the financial crisis (2009), up to roughly 1.3%
- RSA4c: basically identical (max order 5e-5 %)
- RSA5c: Noticeable but noisy deviations throughout, again up to roughly
1.3%
OK, so we're already good with four out of six, fine, including the
outlier handling in cases RSA1, RSA2c, RSA4c. And also the new
working_days option seems to be OK, see case RSA2c.
Right now it's not obvious to me why RSA3 and RSA5c deviate from the
benchmark. But RSA5c is the only one where automatic trading_days are
used, perhaps X13 and Jdemetra do something slightly different there.
So much for this status report, whoever cares about this seasonal
adjustment business.
thanks
sven
2 years, 10 months
- 2
- 5