8:46 p.m.
Dear Allin,
From the previos discussion
I came to think
arima uses standardize(y) + 1
But it is not so:
open greene5_1.gdt
set bfgs_verbskip 999
pops = (pop-mean(pop))/sd(pop)+1
catch arima 0 0; 1 0 ; pop --verbose
arima 0 0; 1 0; pop --x-12-arima
arima 0 0; 1 0; pops --x-12-arima
arima 0 0; 1 0; pops
What is current scaling (if any)?
Oleh
4:25 p.m.
On Sat, 10 Nov 2018, oleg_komashko(a)ukr.net wrote:
Dear Allin,
From the previos discussion
I came to think
arima uses standardize(y) + 1
But it is not so:
open greene5_1.gdt
set bfgs_verbskip 999
pops = (pop-mean(pop))/sd(pop)+1
catch arima 0 0; 1 0 ; pop --verbose
arima 0 0; 1 0; pop --x-12-arima
arima 0 0; 1 0; pops --x-12-arima
arima 0 0; 1 0; pops
What is current scaling (if any)?
The scaling is indeed "standardize(y) + 1", but as things stand we
don't apply it in all cases. The criterion for doing so has been:
abs(mean(y)) > 250 || abs(mean(y)) < 0.01 || sd(y)/abs(mean(y)) < 0.01
In git, I've just adjusted the first test to abs(mean(y)) > 200, which
catches the "pop" case.
Allin
6:22 p.m.
I've just adjusted the first test to abs(mean(y)) > 200
Dear Allin,
1) Do you have examples when doing transformation is
worse than not doing?
2)
The cases I cited earlier for transformation were
from just intuition: I have found them at the very first try.
This way means I have not find all cases for transformation
pop is strongly trended: for such variables mean/sd ratio
is not very meaninful
The situation with inadequate lnl and larege gradient norm
at converging, and bad z-statistics are much more common
then non-convergence
The script attached illustrate it
It should be run before last changes
Ad hoc setting area from non-transformation
is a solution up to I would send a new counter-example
As for me, I'd prefer a new (standard) option, say --transf-y,
or so to force the transformation
Also, bad z-tatistics without --stdx
starts in not exotic cases
Oleh
11 листопада 2018, 18:26:03, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 10 Nov 2018, oleg_komashko(a)ukr.net wrote:
Dear Allin,
From the previos discussion
I came to think
arima uses standardize(y) + 1
But it is not so:
open greene5_1.gdt
set bfgs_verbskip 999
pops = (pop-mean(pop))/sd(pop)+1
catch arima 0 0; 1 0 ; pop --verbose
arima 0 0; 1 0; pop --x-12-arima
arima 0 0; 1 0; pops --x-12-arima
arima 0 0; 1 0; pops
What is current scaling (if any)?
The scaling is indeed "standardize(y) + 1", but as things stand we
don't apply it in all cases. The criterion for doing so has been:
abs(mean(y)) > 250 || abs(mean(y)) < 0.01 || sd(y)/abs(mean(y)) < 0.01
In git, I've just adjusted the first test to abs(mean(y)) > 200, which
catches the "pop" case.
Allin
6:09 p.m.
On Sun, 11 Nov 2018, oleg_komashko(a)ukr.net wrote:
> I've just adjusted the first test to abs(mean(y)) > 200
Dear Allin,
1) Do you have examples when doing transformation is
worse than not doing?
No, I haven't tested for that. I think I've mentioned before, the
conditionality for standardizing is in the function maybe_set_yscale()
in plugin/arma_init.c. You may wish to try experimenting with that and
see what recommendation you come up with.
[...]
As for me, I'd prefer a new (standard) option, say --transf-y,
or so to force the transformation
Could do, but I think we'd be better to try to figure out what is
optimal rather than proliferating options.
Allin
6:49 p.m.
Could do, but I think we'd be better to try to figure out what is
optimal rather than proliferating options.
--x-12-arima behavior tells than even
they
use a different algorithm, in practice the
behavior of their estimates is indistinguisheable
from my arima3
Finding a good non-transforming area could
require months of investigation.
At the other hand, a new option requires
only several minutes of your work.
Please, take into consideration the
following items for arima to be robust
with respect to convergence:
1) mimic a good pattern:
there are a lot of smart guys in US
Census Bureau; they preferred to make
theirs arima in such a way that for all
time I found literally only a couple
examples when arima ... --x-12-arima
fails to converge.
And I am sure that being smart they
do have reasons to comply the way
they do
2) model selection
(i) we have to decide whether to
take logs (or general Box-Cox transformation)
for the original y series
(ii) we have to select d = 0, or d = 1, or d = 2
using a unit root test
(iii) we have to select D = 0, or D = 1
using a seasonal unit root test
(iv) we have to decide whether to include
constant to the model
(v) we have to select the admissible region
for p,q,P,Q
Every one of the stages above can give
type I/II error
This means that after stage
(vI) select p,d,P,Q using some IC
we can come up with a
mis-specified model.
All this tells that in practice the
majority of models we estimate are
mis-specified. A mis-specified model
must be estimated and mis-specification
must be established by standard means:
1) bad polynomial roots
2) autocorrelation
And not the ather way around.
3) marketing consideration
The first thing of the representative user
after a non-convergence case is something
of a kind "bad soft"
Once more: non-convergence is a sub-optimal
mean for bad specification diagnostics.
The standard means are to be preferred:
the first - get estimates
the second - to look at bad roots and
Q'-statistics p-value
Oleh
12 листопада 2018, 20:09:58, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sun, 11 Nov 2018, oleg_komashko(a)ukr.net wrote:
> I've just adjusted the first test to abs(mean(y)) > 200
Dear Allin,
1) Do you have examples when doing transformation is
worse than not doing?
No, I haven't tested for that. I think I've mentioned before, the
conditionality for standardizing is in the function maybe_set_yscale()
in plugin/arma_init.c. You may wish to try experimenting with that and
see what recommendation you come up with.
[...]
As for me, I'd prefer a new (standard) option, say --transf-y,
or so to force the transformation
Could do, but I think we'd be better to try to figure out what is
optimal rather than proliferating options.
Allin
10:26 p.m.
On Mon, 12 Nov 2018, oleg_komashko(a)ukr.net wrote:
--x-12-arima behavior tells than even they
use a different algorithm [...]
We know quite well that the X-13-ARIMA people use a different
algorithm, since they tell us so in their documentation: it's an
algorithm that switches between ML and GLS. We are probably not
going to replicate that, effective as it may be.
in practice the behavior of their estimates is indistinguisheable
from my arima3
Oleh, if you have a definite recommendation for how gretl's arma
should be revised, please say so. Preferably backed up by testing on
a reasonably wide variety of datasets, including the "classic"
benchmarks such as Box-Jenkins.
My objection to adding more arma options is not an objection to
change as such. It's just that if we can find a way to "do it
right", in general, then that should be the default, not something
that an expert has to select.
Allin
10:44 p.m.
On Mon, 12 Nov 2018, Allin Cottrell wrote:
Oleh, if you have a definite recommendation for how gretl's arma
should be
revised, please say so. Preferably backed up by testing on a reasonably wide
variety of datasets, including the "classic" benchmarks such as Box-Jenkins.
My objection to adding more arma options is not an objection to change as
such. It's just that if we can find a way to "do it right", in general,
then
that should be the default, not something that an expert has to select.
And besides: I'm all in favour of making libgretl as efficient as
possible, but if I had to choose where to allocate our not-so-abundant
resources, certainly it wouldn't be in the direction of scraping a few CPU
cycles (or marginally improving the precision) in ARIMA estimation. IMHO
the ARIMA implementation we have now is at least perfectly adequate in the
vast majority of the relevant cases in practice, and in most cases it's
downright excellent.
Certainly it's way better than it was one or two years ago, and this is
mainly thanks to Oleh's testing efforts and Allin's coding work. I reckon
we can live with what we have now, especially considering that ARIMA
modelling is something that I se used less and less often by
practitioners.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
11:22 p.m.
Oleh, if you have a definite recommendation for how gretl's arma
should be revised, please say so.
Yes, of course. and they will take no more than
several dozens
of seconds: just remove ad hoc restrictions on transformatibn
which is in use
This should only affect models with constant.
For no constant for now I propose nothing since
I have not finished yet a reproducible hansl code
for testing
I reckon
we can live with what we have now, especially considering that ARIMA
modelling is something that I se used less and less often by
practitioners. I think, it;a about publications: arima is still good at new generations
of M-competitions
Oleh
13 листопада 2018, 00:26:15, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Mon, 12 Nov 2018, oleg_komashko(a)ukr.net wrote:
--x-12-arima behavior tells than even they
use a different algorithm [...]
We know quite well that the X-13-ARIMA people use a different
algorithm, since they tell us so in their documentation: it's an
algorithm that switches between ML and GLS. We are probably not
going to replicate that, effective as it may be.
in practice the behavior of their estimates is indistinguisheable
from my arima3
Oleh, if you have a definite recommendation for how gretl's arma
should be revised, please say so. Preferably backed up by testing on
a reasonably wide variety of datasets, including the "classic"
benchmarks such as Box-Jenkins.
My objection to adding more arma options is not an objection to
change as such. It's just that if we can find a way to "do it
right", in general, then that should be the default, not something
that an expert has to select.
Allin
7:03 a.m.
Am 13.11.2018 um 00:22 schrieb oleg_komashko(a)ukr.net:
<Jack:>
>we can live with what we have now, especially considering that ARIMA
>modelling is something that I se used less and less often by
>practitioners.
I agree (with the antecedent and the implication)
I think, it;a about publications: arima is still good at new
generations of M-competitions Oleh
Sorry I don't understand. What are
M-competitions?
thanks,
sven
7:08 p.m.
Am 13.11.18 um 08:03 schrieb Sven Schreiber:
Am 13.11.2018 um 00:22 schrieb oleg_komashko(a)ukr.net:
> <Jack:>
> >we can live with what we have now, especially considering that ARIMA
> >modelling is something that I se used less and less often by
> >practitioners.
I agree (with the antecedent and the implication)
> I think, it;a about publications: arima is still good at new
> generations of M-competitions Oleh
Sorry I don't understand. What are M-competitions?
I guess, Oleg means the M-forecasting competition series. M4 was the
latest one:
https://www.m4.unic.ac.cy/
Artur
2238
days inactive
2242
days old
9 comments
5 participants
participants (5)
-
Allin Cottrell -
Artur T. -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber