9:37 p.m.
Dear all,
An example to reproduce
function void arma11_via_kalman (series y)
/* listing 33.1 with '--hessiaan' dropped */
/* parameter initialization */
scalar phi = 0
scalar theta = 0
scalar sigma = 1
/* state-space model setup */
matrix H = {1; theta}
matrix F = {phi, 0; 1, 0}
matrix Q = {sigma^2, 0; 0, 0}
bundle kb = ksetup(y, H, F, Q)
/* maximum likelihood estimation */
mle logl = ERR ? NA : kb.llt
kb.obsymat[2] = theta
kb.statemat[1,1] = phi
kb.statevar[1,1] = sigma^2
ERR = kfilter(&kb)
params phi theta sigma
end mle
end function
set verbose on
arma11_via_kalman(pop)
arma 1 1; pop --nc --conditional
catch arma 1 1; pop --nc
catch arma 1 1; pop --nc --x-12-arima
Question: why the natives do not use
this trick?
Oleh
10:44 p.m.
The bug is very small, run
ma = {0.00001,0.00001}
set initvals ma
catch arma 1 1; pop --nc --opg
ma = {-0.9,-0.9}
set initvals ma
catch arma 1 1; pop --nc --opg
ma = {0,0}
set initvals ma
catch arma 1 1; pop --nc --opg
set initvals auto
catch arma 1 1; pop --nc --opg
Oleh
20 лютого 2018, 23:37:30, від oleg_komashko(a)ukr.net:
Dear all,
An example to reproduce
function void arma11_via_kalman (series y)
/* listing 33.1 with '--hessiaan' dropped */
/* parameter initialization */
scalar phi = 0
scalar theta = 0
scalar sigma = 1
/* state-space model setup */
matrix H = {1; theta}
matrix F = {phi, 0; 1, 0}
matrix Q = {sigma^2, 0; 0, 0}
bundle kb = ksetup(y, H, F, Q)
/* maximum likelihood estimation */
mle logl = ERR ? NA : kb.llt
kb.obsymat[2] = theta
kb.statemat[1,1] = phi
kb.statevar[1,1] = sigma^2
ERR = kfilter(&kb)
params phi theta sigma
end mle
end function
set verbose on
arma11_via_kalman(pop)
arma 1 1; pop --nc --conditional
catch arma 1 1; pop --nc
catch arma 1 1; pop --nc --x-12-arima
Question: why the natives do not use
this trick?
Oleh
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
12:31 a.m.
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
The bug is very small, run
ma = {0.00001,0.00001}
set initvals ma
catch arma 1 1; pop --nc --opg
ma = {-0.9,-0.9}
set initvals ma
catch arma 1 1; pop --nc --opg
ma = {0,0}
set initvals ma
catch arma 1 1; pop --nc --opg
set initvals auto
catch arma 1 1; pop --nc --opg
Using what dataset, please?
Allin
1:21 a.m.
It was on the previous message , greene5_1
I think, default init values here have roots inside the unit circle
I propose the following
/*
A method for safe initial values
Whatever it be it can give roots inside the unit circle
This can be easily agjusted
Hansl has filter() so expandig factored polynomials
is not a problem
Suppose, we have found (1,-phi_1, -phi_k)
as init. values whatever way using non-linear AR,
conditional loglic, etc
1) check absolute value of roots
2) factor
3) scale improper roots to have abs. value, say 1.01
4) expand
this way we would have a new set of phi_1,..,phi_k
which would be in admissible domain
*/
Oleh
Another problem is rescaling BFGS
when init values are very good
try
open bjg.gdt
arima 2 1 2; 2 1 2; lg
then use
arima 2 1 2; 2 1 2; lg --x-12-arima
they use iterative GLS instead
insert them into set initvals:
they are very close to solutions
but the time gain is very moderate
It seems there are not very
efficient algoritm when
iteration step bumps into
the border of admissible area
21 лютого 2018, 02:32:00, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
The bug is very small, run
ma = {0.00001,0.00001}
set initvals ma
catch arma 1 1; pop --nc --opg
ma = {-0.9,-0.9}
set initvals ma
catch arma 1 1; pop --nc --opg
ma = {0,0}
set initvals ma
catch arma 1 1; pop --nc --opg
set initvals auto
catch arma 1 1; pop --nc --opg
Using what dataset, please?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
1:57 a.m.
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
It was on the previous message , greene5_1
I'm going to press my point: your previous message did _not_ refer
to any data file and so was equally incomprehensible. Please, if you
post hansl code that is supposed to be runnable, include a reference
to a specific data file (or a suitable "nulldata" command plus
appropriate follow-up).
That said, I now take your point: you present a number of possible
manual initializations of an ARMA(1,1) model of the US population
variable from the greene5_1 dataset, all of which work to produce ML
estimates, yet if the initialization is left to the gretl default,
estimation fails at the first step. I agree, this suggests there is
something wrong with our automatic initialization. We'll look into
it as you suggest.
Allin
4:37 a.m.
On Tue, 20 Feb 2018, Allin Cottrell wrote:
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
> It was on the previous message , greene5_1
I'm going to press my point: your previous message did _not_ refer to any
data file and so was equally incomprehensible. Please, if you post hansl code
that is supposed to be runnable, include a reference to a specific data file
(or a suitable "nulldata" command plus appropriate follow-up).
That said, I now take your point: you present a number of possible manual
initializations of an ARMA(1,1) model of the US population variable from the
greene5_1 dataset, all of which work to produce ML estimates, yet if the
initialization is left to the gretl default, estimation fails at the first
step. I agree, this suggests there is something wrong with our automatic
initialization. We'll look into it as you suggest.
It should be said that the variable "pop" in the greene5_1 dataset is, at
least I(1), so the constant-less ARMA(1,1) Oleh is estimating is grossly
misspecified. Our present initialisation strategies (Hanna-Rissanen),
for example hinge on the fact that the specification one is trying to
estimate is not too heavily at odds with the data. Debatable, perhaps, but
not meaningless IMO.
-------------------------------------------------------
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
-------------------------------------------------------
10 a.m.
It is worse then I(1) : auto_arima with d=1 gives a lot
of non-estimated models. pop should be transformed to logs, but...
In my opinion the first thing to check with
init values is to compute absolute values
of the corresponding polinomial
I suspect, some are outside the admissibility region
Another problem:
when mle block fails to compute hessian it tries to compute opg
arima fails in such situations one should input --opg by hand
Yet another problem is the behavior of BFGLS with good init values
With bjg.gdt arima 2 1 2; 2 1 2; lg takes ~60 seconds (R's arima only ~ 14 seconds)
If insert ints from arima 2 1 2; 2 1 2; lg --x-12-arima
with arima 2 1 2; 2 1 2; lg I have ~40 seconds: the gain from
very good inits givess very little
Oleh
21 лютого 2018, 06:37:38, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Tue, 20 Feb 2018, Allin Cottrell wrote:
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
> It was on the previous message , greene5_1
I'm going to press my point: your previous message did _not_ refer to any
data file and so was equally incomprehensible. Please, if you post hansl code
that is supposed to be runnable, include a reference to a specific data file
(or a suitable "nulldata" command plus appropriate follow-up).
That said, I now take your point: you present a number of possible manual
initializations of an ARMA(1,1) model of the US population variable from the
greene5_1 dataset, all of which work to produce ML estimates, yet if the
initialization is left to the gretl default, estimation fails at the first
step. I agree, this suggests there is something wrong with our automatic
initialization. We'll look into it as you suggest.
It should be said that the variable "pop" in the greene5_1 dataset is, at
least I(1), so the constant-less ARMA(1,1) Oleh is estimating is grossly
misspecified. Our present initialisation strategies (Hanna-Rissanen),
for example hinge on the fact that the specification one is trying to
estimate is not too heavily at odds with the data. Debatable, perhaps, but
not meaningless IMO.
-------------------------------------------------------
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
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:10 a.m.
Am 21.02.2018 um 11:00 schrieb oleg_komashko(a)ukr.net:
In my opinion the first thing to check with
init values is to compute absolute values
of the corresponding polinomial
I suspect, some are outside the admissibility region
Perhaps you could check your
example with the polroots() function. I
tend to agree that the algorithm should avoid initial values that are in
an "inadmissible" region. OTOH sometimes it is perfectly valid to
estimate models with --for example-- explosive roots. So maybe it's not
always clear a priori what "admissible" really means.
cheers,
sven
10:50 a.m.
Even without polroots():
open greene5_1.gdt
ols pop 0 pop(-1) -q
theta0 = $coeff
ma = theta0|0
set initvals ma
arima 1 1; pop --verbose --opg
Oleh
P.S.
/*
A method for safe initial values
Whatever it be it can give roots inside the unit circle
This can be easily agjusted
Hansl has filter() so expanding factored polynomials
is not a problem
Suppose, we have found (1,-phi_1, -phi_k)
as init. values whatever way using (non)linear AR,
conditional loglik, etc
1) check absolute value of roots
2) factor
3) scale improper roots to have abs. value, say 1.01
4) expand
this way we would have a new set of phi_1,..,phi_k
which would be in admissible domain
*/
21 лютого 2018, 12:10:27, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 21.02.2018 um 11:00 schrieb oleg_komashko(a)ukr.net:
In my opinion the first thing to check with
init values is to compute absolute values
of the corresponding polinomial
I suspect, some are outside the admissibility region
Perhaps you could check your
example with the polroots() function. I
tend to agree that the algorithm should avoid initial values that are in
an "inadmissible" region. OTOH sometimes it is perfectly valid to
estimate models with --for example-- explosive roots. So maybe it's not
always clear a priori what "admissible" really means.
cheers,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
3:25 p.m.
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
when mle block fails to compute hessian it tries to compute opg
arima fails in such situations one should input --opg by hand
Thanks for pointing this out.
The intended behavior of "arma" is that we fall back to OPG for the
covariance matrix if computation of the Hessian fails -- unless the
--hessian option is given, in which case an error is flagged if the
request cannot be met.
This facility got broken at some point, but it's now reinstated in
git.
Speed:
With bjg.gdt arima 2 1 2; 2 1 2; lg takes ~60 seconds
(R's arima only ~ 14 seconds)
If insert [initializer] from arima 2 1 2; 2 1 2; lg --x-12-arima
with arima 2 1 2; 2 1 2; lg I have ~40 seconds: the gain from
very good inits gives very little
We're aware that our exact ML estimation of complex ARIMA models via
the Kalman filter is slow compared to some other software. This is
something we're looking into. One point to note is that our
implementation arguably offers "surplus precision" as it stands. For
the specification above, for example, gretl gets a somewhat greater
loglikelihood than x13as. (I haven't yet figured out how to get R's
arima() to estimate this model.)
Allin
5 p.m.
gretl gets a somewhat greater
loglikelihood than x13as
x13as use absolutely different method: iterative GLS
https://pdfs.semanticscholar.org/77a0/3722ccff2226737ae78903d6005bb0f7549...
If substarct calling API time it can be ~100 times more fast
(it gives 3 sec with the same model)
R variant is essentially the same: exact lik. via Kalman in normal situations
as with (bjg) arima 0 1 1; 0 1 1; lg it is very similar in time and results and
loglik But when number of (S)MA terms increase something going on with the native arima
Also I attach my hansl code which makes safe inits:
It does exactly nothing in the situations when the current default works
and does something when it fails
Oleh
21 лютого 2018, 17:25:29, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
when mle block fails to compute hessian it tries to compute opg
arima fails in such situations one should input --opg by hand
Thanks for pointing this out.
The intended behavior of "arma" is that we fall back to OPG for the
covariance matrix if computation of the Hessian fails -- unless the
--hessian option is given, in which case an error is flagged if the
request cannot be met.
This facility got broken at some point, but it's now reinstated in
git.
Speed:
With bjg.gdt arima 2 1 2; 2 1 2; lg takes ~60 seconds
(R's arima only ~ 14 seconds)
If insert [initializer] from arima 2 1 2; 2 1 2; lg --x-12-arima
with arima 2 1 2; 2 1 2; lg I have ~40 seconds: the gain from
very good inits gives very little
We're aware that our exact ML estimation of complex ARIMA models via
the Kalman filter is slow compared to some other software. This is
something we're looking into. One point to note is that our
implementation arguably offers "surplus precision" as it stands. For
the specification above, for example, gretl gets a somewhat greater
loglikelihood than x13as. (I haven't yet figured out how to get R's
arima() to estimate this model.)
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
1:24 p.m.
On Wed, 21 Feb 2018, Riccardo (Jack) Lucchetti wrote:
On Tue, 20 Feb 2018, Allin Cottrell wrote:
> On Wed, 21 Feb 2018, oleg_komashko(a)ukr.net wrote:
>
>> It was on the previous message , greene5_1
>
> I'm going to press my point: your previous message did _not_ refer to any
> data file and so was equally incomprehensible. Please, if you post hansl
> code that is supposed to be runnable, include a reference to a specific
> data file (or a suitable "nulldata" command plus appropriate follow-up).
>
> That said, I now take your point: you present a number of possible manual
> initializations of an ARMA(1,1) model of the US population variable from
> the greene5_1 dataset, all of which work to produce ML estimates, yet if
> the initialization is left to the gretl default, estimation fails at the
> first step. I agree, this suggests there is something wrong with our
> automatic initialization. We'll look into it as you suggest.
It should be said that the variable "pop" in the greene5_1 dataset is, at
least I(1), so the constant-less ARMA(1,1) Oleh is estimating is grossly
misspecified.
Indeed. I missed that at first but it's obviously true. x13as will not
produce estimates in this case: "Estimation failed to converge".
Allin
12:42 a.m.
On Tue, 20 Feb 2018, oleg_komashko(a)ukr.net wrote:
Dear all,
An example to reproduce
function void arma11_via_kalman (series y)
/* listing 33.1 with '--hessiaan' dropped */
/* parameter initialization */
scalar phi = 0
scalar theta = 0
scalar sigma = 1
/* state-space model setup */
matrix H = {1; theta}
matrix F = {phi, 0; 1, 0}
matrix Q = {sigma^2, 0; 0, 0}
bundle kb = ksetup(y, H, F, Q)
/* maximum likelihood estimation */
mle logl = ERR ? NA : kb.llt
kb.obsymat[2] = theta
kb.statemat[1,1] = phi
kb.statevar[1,1] = sigma^2
ERR = kfilter(&kb)
params phi theta sigma
end mle
end function
set verbose on
arma11_via_kalman(pop)
arma 1 1; pop --nc --conditional
catch arma 1 1; pop --nc
catch arma 1 1; pop --nc --x-12-arima
Question: why the natives do not use this trick?
Oleh, you are altogether too mysterious. Where is this 'pop' coming
from? What are you talking about?
I strongly suspect you have a valid point to make, but you have not
given me the slightest clue what it is.
Allin
1:59 a.m.
I am sorry :
while copy-pasting I missed top
with open greene5_1.gdt
I an updating lagreg
to have full selection with unit ans
seasonal unit root testing
It makes traces of catch-ed non-estimated
models and of course, it id slow (without --x-12-arima option)
so I have found a lot of situations
Also when substract calling time --x-12-arima can be
100 times faster I questioned why and found they use iterative GLS
Oleh
21 лютого 2018, 02:42:33, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Tue, 20 Feb 2018, oleg_komashko(a)ukr.net wrote:
Dear all,
An example to reproduce
function void arma11_via_kalman (series y)
/* listing 33.1 with '--hessiaan' dropped */
/* parameter initialization */
scalar phi = 0
scalar theta = 0
scalar sigma = 1
/* state-space model setup */
matrix H = {1; theta}
matrix F = {phi, 0; 1, 0}
matrix Q = {sigma^2, 0; 0, 0}
bundle kb = ksetup(y, H, F, Q)
/* maximum likelihood estimation */
mle logl = ERR ? NA : kb.llt
kb.obsymat[2] = theta
kb.statemat[1,1] = phi
kb.statevar[1,1] = sigma^2
ERR = kfilter(&kb)
params phi theta sigma
end mle
end function
set verbose on
arma11_via_kalman(pop)
arma 1 1; pop --nc --conditional
catch arma 1 1; pop --nc
catch arma 1 1; pop --nc --x-12-arima
Question: why the natives do not use this trick?
Oleh, you are altogether too mysterious. Where is this 'pop' coming
from? What are you talking about?
I strongly suspect you have a valid point to make, but you have not
given me the slightest clue what it is.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2496
days inactive
2497
days old
13 comments
4 participants
participants (4)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber