2:40 p.m.
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
5:26 p.m.
On Thu, 3 Feb 2022, Sven Schreiber wrote:
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?)
No there isn't.
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.
Interesting, thanks for investigating. A couple of comments. The
"RSA" naming comes from TRAMO-SEATS, maybe it's difficult to map
exactly from X13 options to TRAMO ones? Plus, it seems a bit strange
that with all those RSAs there isn't one that employs X13's default
treatment of outliers.
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.
Maybe try with the seats option to deseas() activated?
Could you perhaps post the RJdemetra results somewhere so other
could examine the differences? Thanks.
Allin
7:14 a.m.
Am 03.02.2022 um 23:26 schrieb Allin Cottrell:
On Thu, 3 Feb 2022, Sven Schreiber wrote:
> (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?)
No there isn't.
:-)
>
Interesting, thanks for investigating. A couple of comments. The "RSA"
naming comes from TRAMO-SEATS, maybe it's difficult to map exactly
from X13 options to TRAMO ones? Plus, it seems a bit strange that with
all those RSAs there isn't one that employs X13's default treatment of
outliers.
Well, there are three cases where the options seem to match pretty well.
(The fourth case RSA0 doesn't have much options, only the airline model.)
With the outliers there, it's all or nothing. (Remember, "all" means
check all, not necessarily include all.) Don't know where X13's default
comes from, maybe it's historical path dependence which Jdemetra had no
reason to follow.
> 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.
Maybe try with the seats option to deseas() activated?
Cannot hurt to try that,
yes.
Could you perhaps post the RJdemetra results somewhere so other could
examine the differences? Thanks.
It's not a big file, so I'm attaching the data in the hope that it goes
through.
thanks
sven
1:37 p.m.
On Fri, 4 Feb 2022, Sven Schreiber wrote:
Am 03.02.2022 um 23:26 schrieb Allin Cottrell:
>
> Could you perhaps post the RJdemetra results somewhere so other could
> examine the differences? Thanks.
It's not a big file, so I'm attaching the data in the hope that it goes
through.
Thanks, I've now installed RJDemetra (RJD for short) and can confirm
the results you posted. In the cases where there's noticeable
disagreement (RSA3, RSA5c) the programs are either arriving at a
different ARIMA specification, choosing different calendar effects,
or finding different (but overlapping) outliers. Here's a summary,
gleaned from the verbose printouts from RJD and X13A.
RSA3
----
RJD:
arima (3 1 1)(0 1 1) in levels + 5 outliers
(outliers: TC (4-2020), AO (3-2020), LS (11-2008),
AO (5-2011), TC (2-2009)
Log likelihood = -898.2, aicc = 1819
X13A, b58:
arima (2 1 0)(0 1 1) in levels + 3 outliers
(outliers: LS (11-2008), TC (3-2020), TC (4-2020)
Log likelihood = -916.1, aicc = 1846.5
X13A, b39:
arima (3 1 1)(0 1 1) in levels + 3 outliers
Log likelihood = -914.5, aicc = 1847.5
So this is a case where the two X13A builds I've tried disagree.
Build 58 struggles with RSA3 on these data -- takes over 20 times as
long as any of the other specs -- while build 39 completes in
reasonable time. If we believe RJD's loglikelihood and AICC, it's
doing a little better.
RSA5c
-----
RJD:
arima (2 1 1)(0 1 1) in levels + 4 outliers + 8 calendar effects
(calendar: 6 daily coeffs plus Leap year + Easter[1])
Log likelihood = -799.1, aicc = 1634
X13A, b58 and b39 (identical):
arima (2 1 1)(0 1 1) in levels + 5 outliers + 2 calendar effects
(calendar: Weekday (1-coeff) and Easter[1])
Log likelihood = -795.1, aicc = 1617
In this case X13A does better wrt loglik and AICC. I'm not sure if
the respective programs are starting with the same "test-down-from"
spec for calendar effects; it doesn't look like it.
Allin
5:20 a.m.
Am 04.02.2022 um 19:37 schrieb Allin Cottrell:
Thanks, I've now installed RJDemetra (RJD for short) and can confirm
the results you posted. In the cases where there's noticeable
disagreement (RSA3, RSA5c) the programs are either arriving at a
different ARIMA specification, choosing different calendar effects, or
finding different (but overlapping) outliers. Here's a summary,
gleaned from the verbose printouts from RJD and X13A.
Thanks for the analysis,
Allin.
RSA3
----
RJD:
arima (3 1 1)(0 1 1) in levels + 5 outliers
(outliers: TC (4-2020), AO (3-2020), LS (11-2008),
AO (5-2011), TC (2-2009)
Log likelihood = -898.2, aicc = 1819
X13A, b58:
arima (2 1 0)(0 1 1) in levels + 3 outliers
(outliers: LS (11-2008), TC (3-2020), TC (4-2020)
Log likelihood = -916.1, aicc = 1846.5
X13A, b39:
arima (3 1 1)(0 1 1) in levels + 3 outliers
Log likelihood = -914.5, aicc = 1847.5
So this is a case where the two X13A builds I've tried disagree. Build
58 struggles with RSA3 on these data -- takes over 20 times as long as
any of the other specs -- while build 39 completes in reasonable time.
What's
the background on those specific builds, I mean why did you
choose exactly 39 and 58? I suppose one is the latest, but the other?
If we believe RJD's loglikelihood and AICC, it's doing a
little better.
I don't think we should compare the likelihood over different
specifications, especially different number of outliers. OK, the AICC
may be a different story, but for outlier-style regressors it's still
not so clear.
RSA5c
-----
RJD:
arima (2 1 1)(0 1 1) in levels + 4 outliers + 8 calendar effects
(calendar: 6 daily coeffs plus Leap year + Easter[1])
Log likelihood = -799.1, aicc = 1634
X13A, b58 and b39 (identical):
arima (2 1 1)(0 1 1) in levels + 5 outliers + 2 calendar effects
(calendar: Weekday (1-coeff) and Easter[1])
Log likelihood = -795.1, aicc = 1617
In this case X13A does better wrt loglik and AICC.
Again, more outliers get a
better AICC. I wonder if that's already a
pattern.
I'm not sure if the respective programs are starting with the
same
"test-down-from" spec for calendar effects; it doesn't look like it.
Do you know what "Weekday (1-coeff)" means? The RSA5c spec starts with
different regressors for each day of the week AFAIK, and our
"trading_days" is transformed into X13's "td" if I remember
correctly.
Does it mean of those regressors only one survived? Or is there a
problem somewhere and it effectively switched to "td1coef" somehow
(which our "working_days" is supposed to trigger)?
In general there are a billion ways to implement this search strategy,
of course. In the X13 doc I read somewhere that they hold the Arima
model fixed for that search; this is very reasonable, but obviously a
simplification due to the computational burden. Jdemetra being more
recent, maybe they skip some of the simplifications.
(Plus, there's the notorious leap year handling...)
cheers
sven
3:34 p.m.
On Sat, 5 Feb 2022, Sven Schreiber wrote:
Am 04.02.2022 um 19:37 schrieb Allin Cottrell:
>
> Thanks, I've now installed RJDemetra (RJD for short) and can
> confirm the results you posted. In the cases where there's
> noticeable disagreement (RSA3, RSA5c) the programs are either
> arriving at a different ARIMA specification, choosing different
> calendar effects, or finding different (but overlapping)
> outliers. Here's a summary, gleaned from the verbose printouts
> from RJD and X13A.
Thanks for the analysis, Allin.
[...analysis of "RSA3" case, using both X13A b58 and b39]
What's the background on those specific builds, I mean why did
you
choose exactly 39 and 58? I suppose one is the latest, but the
other?
b58 is the latest. b39 happens to have been current the last time I
built X13A for use with gretl, some years back, and I kept the
source code around.
> If we believe RJD's loglikelihood and AICC, it's doing a
little
> better.
I don't think we should compare the likelihood over different
specifications, especially different number of outliers.
Agreed.
OK, the AICC may be a different story, but for outlier-style
regressors it's still not so clear.
OK, fair point.
On the "RSA5c" set of options:
> RJD[emetra]:
> arima (2 1 1)(0 1 1) in levels + 4 outliers + 8 calendar effects
> (calendar: 6 daily coeffs plus Leap year + Easter[1])
> Log likelihood = -799.1, aicc = 1634
>
> X13A, b58 and b39 (identical):
> arima (2 1 1)(0 1 1) in levels + 5 outliers + 2 calendar effects
> (calendar: Weekday (1-coeff) and Easter[1])
> Log likelihood = -795.1, aicc = 1617
Again, more outliers get a better AICC. I wonder if that's already a
pattern.
Hmm, could be.
> I'm not sure if the respective programs are starting with the
same
> "test-down-from" spec for calendar effects; it doesn't look like it.
Do you know what "Weekday (1-coeff)" means?
That was my transcription based on this literal X13A output:
<X13A>
Regression Model
-------------------------------------------------------------------
Parameter Standard
Variable Estimate Error t-value
-------------------------------------------------------------------
Leap Year 2.0903 0.68242 3.06
1-Coefficient Trading Day
Weekday 0.6927 0.03090 22.42
**Sat/Sun (derived) -1.7316 0.07725 -22.42
Easter[1] -2.5476 0.43436 -5.87
</X13A>
The RSA5c spec starts with different regressors for each day of
the week AFAIK, and our "trading_days" is transformed into X13's
"td" if I remember correctly. Does it mean of those regressors
only one survived? Or is there a problem somewhere and it
effectively switched to "td1coef" somehow (which our
"working_days" is supposed to trigger)?
Well, there's nothing explicit in the X13A output to say that the
results above represent an AICC-based pruning of a less parsimonious
starting point. On the other hand, if I force the less parsimonious
version by passing to X13A
regression{ variables = (td easter[1]) }
then I get all 6 td coefficients but 1 fewer outliers, and a worse
AICC (plus a worse loglik despite the extra parameters, FWIW). So it
could well be that X13A has silently pruned in the background.
In general there are a billion ways to implement this search
strategy, of course. In the X13 doc I read somewhere that they
hold the Arima model fixed for that search; this is very
reasonable, but obviously a simplification due to the
computational burden. Jdemetra being more recent, maybe they skip
some of the simplifications.
Hmm. When both RJD and X13A are fed the RSA5c spec, they arrive at
the same ARIMA (2 1 1)(0 1 1). But when X13A is forced to include 6
trading-day coeffs it switches to (3 1 1)(0 1 1). So I'm not seeing
any evidence of X13A skipping complications that are handled by RJD.
Or am I missing your point?
(Plus, there's the notorious leap year handling...)
OMG, I don't even want to think about that!
Allin
1016
days inactive
1018
days old
5 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber