12:16 p.m.
When you right click on a time series in your dataset and select
'correlogram', the autocorrelations, partial autocorrelations, Q
statistic (Ljung-Box) and their pvalues are printed and these pvalues
are correctly obtained from a chi-square distribution with M degrees of
freedom being M the number of autocorrelations tested.
But when you estimate an ARIMA model and, in the model window, you
select Graphs->residual correlogram, I think gretl is applying the same
function so the output window is printing the pvalues obtained from a
chi-square (M) while now this should be (M-p-q). So the pvalues shown
are incorrect. In fact if, in the model window, you select
Tests->Autocorrelation, you may obtain the Ljung-Box statistic with the
pvalue obtained correctly from a chi-square (M-p-q)
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.eus <mailto:ignacio.diaz-emparanza@ehu.eus>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ehu.eus/es/web/ea3* <http://www.ehu.eus/es/web/ea3>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
12:57 p.m.
On Tue, 3 Mar 2015, Ignacio Diaz-Emparanza wrote:
When you right click on a time series in your dataset and select
'correlogram', the autocorrelations, partial autocorrelations, Q statistic
(Ljung-Box) and their pvalues are printed and these pvalues are correctly
obtained from a chi-square distribution with M degrees of freedom being M the
number of autocorrelations tested.
But when you estimate an ARIMA model and, in the model window, you select
Graphs->residual correlogram, I think gretl is applying the same function so
the output window is printing the pvalues obtained from a chi-square (M)
while now this should be (M-p-q). So the pvalues shown are incorrect. In fact
if, in the model window, you select Tests->Autocorrelation, you may obtain
the Ljung-Box statistic with the pvalue obtained correctly from a chi-square
(M-p-q)
You're absolutely right. I remember I noticed the same thing back in 2010
or so and thought to myself "we have to get this fixed", but then, there's
only something more urgent to do.
-------------------------------------------------------
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
-------------------------------------------------------
1:48 p.m.
Am 03.03.2015 um 13:57 schrieb Riccardo (Jack) Lucchetti:
You're absolutely right. I remember I noticed the same thing back in
2010 or so and thought to myself "we have to get this fixed", but then,
there's only something more urgent to do.
That's what the bug tracker on sourceforge is there for. I admit I
should look at and administrate it more often, but I think it's useful
as an internal to-do list but also as an external documentation resource
for stuff like this.
One may think that fixing this trivial kind of bug takes no more time
than posting the bug and thus if the devels do not have the time to fix
the bug right away, they also don't have time to open a bug report. I
actually think that it's true psychologically, but I would seriously
ask: is it really really true that fixing the bug is quicker? Given that
after the quick change of the source you also have to do some testing
etc. So please just write a two-liner in the bug tracker and then this
will not take another five years to fix.
cheers,
sven
2:45 p.m.
On Tue, 3 Mar 2015, Sven Schreiber wrote:
Am 03.03.2015 um 13:57 schrieb Riccardo (Jack) Lucchetti:
>
> You're absolutely right. I remember I noticed the same thing back
> in
> 2010 or so and thought to myself "we have to get this fixed", but
> then,
> there's only something more urgent to do.
>
That's what the bug tracker on sourceforge is there for. I admit I
should look at and administrate it more often, but I think it's
useful as an internal to-do list but also as an external
documentation resource for stuff like this.
One may think that fixing this trivial kind of bug takes no more time
than posting the bug and thus if the devels do not have the time to
fix the bug right away, they also don't have time to open a bug
report. I actually think that it's true psychologically, but I would
seriously ask: is it really really true that fixing the bug is
quicker? Given that after the quick change of the source you also
have to do some testing etc. So please just write a two-liner in the
bug tracker and then this will not take another five years to fix.
Sven,
I take your point. However, I've just committed a fix in CVS for the ARMA
case (please test); I guess we ought to do something similar for OLS, but
I'm not quite sure how to proceed. Allin? Ignacio?
-------------------------------------------------------
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
-------------------------------------------------------
3:05 p.m.
On Tue, 3 Mar 2015, Riccardo (Jack) Lucchetti wrote:
On Tue, 3 Mar 2015, Sven Schreiber wrote:
> Am 03.03.2015 um 13:57 schrieb Riccardo (Jack) Lucchetti:
>
>>
>> You're absolutely right. I remember I noticed the same thing back in
>> 2010 or so and thought to myself "we have to get this fixed", but
then,
>> there's only something more urgent to do.
>>
>
> That's what the bug tracker on sourceforge is there for. I admit I should
> look at and administrate it more often, but I think it's useful as an
> internal to-do list but also as an external documentation resource for
> stuff like this.
>
> One may think that fixing this trivial kind of bug takes no more time than
> posting the bug and thus if the devels do not have the time to fix the bug
> right away, they also don't have time to open a bug report. I actually
> think that it's true psychologically, but I would seriously ask: is it
> really really true that fixing the bug is quicker? Given that after the
> quick change of the source you also have to do some testing etc. So please
> just write a two-liner in the bug tracker and then this will not take
> another five years to fix.
Sven,
I take your point. However, I've just committed a fix in CVS for the ARMA
case (please test); I guess we ought to do something similar for OLS, but I'm
not quite sure how to proceed. Allin? Ignacio?
I was thinking along the same lines as in your patch for library.c in
the GUI, but it's not that simple. Two things have to be answered.
1) What's the appropriate generalization of "m-p-q" for cases such as
"gappy" arma and seasonal arma? Is it just the total number of AR and
MA coefficients estimated?
2) What should we do with our current table of results, which shows
ACF, PACF, Q statistic and p-value from m = 1 up to a specified
maximum lag? Obviously we can't show a p-value when the df is < 0.
Should we suppress all of the rows until m is large enough that df >
0, or just not print Q + p-value for the initial rows?
Allin
3:38 p.m.
On Tue, 3 Mar 2015, Allin Cottrell wrote:
I was thinking along the same lines as in your patch for library.c in
the
GUI, but it's not that simple. Two things have to be answered.
1) What's the appropriate generalization of "m-p-q" for cases such as
"gappy"
arma and seasonal arma? Is it just the total number of AR and MA coefficients
estimated?
Yes, I agree, this is why I inserted the comment line
/* probably wrong but just for testing by now */
However, this is no more wrong than what we were doing before and arguably
right in the most common cases.
2) What should we do with our current table of results, which shows
ACF,
PACF, Q statistic and p-value from m = 1 up to a specified maximum lag?
Obviously we can't show a p-value when the df is < 0. Should we suppress all
of the rows until m is large enough that df > 0, or just not print Q +
p-value for the initial rows?
Good point. We may want to drop the Qs for the firs m rows, the rationale
being: the sample autocorrelations (either total and partial) are
statistics which can be given a descriptive interpretation, so there's no
reason to drop them. That said, they also form the basis for the Q
statistic, which is probably only worth reporting when it can be given a
meaningful interpretation as a test statistic (that is, when df>0).
-------------------------------------------------------
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
-------------------------------------------------------
4:18 p.m.
On Tue, 3 Mar 2015, Riccardo (Jack) Lucchetti wrote:
On Tue, 3 Mar 2015, Allin Cottrell wrote:
> I was thinking along the same lines as in your patch for library.c in the
> GUI, but it's not that simple. Two things have to be answered.
>
> 1) What's the appropriate generalization of "m-p-q" for cases such as
> "gappy" arma and seasonal arma? Is it just the total number of AR and MA
> coefficients estimated?
Yes, I agree, this is why I inserted the comment line
/* probably wrong but just for testing by now */
However, this is no more wrong than what we were doing before and arguably
right in the most common cases.
> 2) What should we do with our current table of results, which shows ACF,
> PACF, Q statistic and p-value from m = 1 up to a specified maximum lag?
> Obviously we can't show a p-value when the df is < 0. Should we suppress
> all of the rows until m is large enough that df > 0, or just not print Q +
> p-value for the initial rows?
Good point. We may want to drop the Qs for the firs m rows, the rationale
being: the sample autocorrelations (either total and partial) are statistics
which can be given a descriptive interpretation, so there's no reason to drop
them. That said, they also form the basis for the Q statistic, which is
probably only worth reporting when it can be given a meaningful
interpretation as a test statistic (that is, when df>0).
OK, that's now done in CVS and snapshots (print ACF and PACF "all the
way", but Q and p-value only when df > 0).
Allin
5:36 p.m.
On 03/03/15 17:18, Allin Cottrell wrote:
On Tue, 3 Mar 2015, Riccardo (Jack) Lucchetti wrote:
> On Tue, 3 Mar 2015, Allin Cottrell wrote:
>
>> I was thinking along the same lines as in your patch for library.c
>> in the GUI, but it's not that simple. Two things have to be answered.
>>
>> 1) What's the appropriate generalization of "m-p-q" for cases such
>> as "gappy" arma and seasonal arma? Is it just the total number of AR
>> and MA coefficients estimated?
>
> Yes, I agree, this is why I inserted the comment line
>
> /* probably wrong but just for testing by now */
>
> However, this is no more wrong than what we were doing before and
> arguably right in the most common cases.
Yes I agree on tis as well. M-k where
k is the number of coefficients
estimated.
>
>> 2) What should we do with our current table of results, which shows
>> ACF, PACF, Q statistic and p-value from m = 1 up to a specified
>> maximum lag? Obviously we can't show a p-value when the df is < 0.
>> Should we suppress all of the rows until m is large enough that df >
>> 0, or just not print Q + p-value for the initial rows?
>
> Good point. We may want to drop the Qs for the firs m rows, the
> rationale being: the sample autocorrelations (either total and
> partial) are statistics which can be given a descriptive
> interpretation, so there's no reason to drop them. That said, they
> also form the basis for the Q statistic, which is probably only worth
> reporting when it can be given a meaningful interpretation as a test
> statistic (that is, when df>0).
OK, that's now done in CVS and snapshots (print ACF and PACF "all the
way", but Q and p-value only when df > 0).
I think this is OK, Q and p-value only when there are df>0.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.eus <mailto:ignacio.diaz-emparanza@ehu.eus>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ehu.eus/es/web/ea3* <http://www.ehu.eus/es/web/ea3>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
6:10 p.m.
On 03/03/15 17:18, Allin Cottrell wrote:
OK, that's now done in CVS and snapshots (print ACF and PACF
"all the
way", but Q and p-value only when df > 0).
I confirm this is working OK now.
Thanks!
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.eus <mailto:ignacio.diaz-emparanza@ehu.eus>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ehu.eus/es/web/ea3* <http://www.ehu.eus/es/web/ea3>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
4:31 p.m.
Am 03.03.2015 um 16:05 schrieb Allin Cottrell:
I was thinking along the same lines as in your patch for library.c in
the GUI, but it's not that simple. Two things have to be answered.
1) What's the appropriate generalization of "m-p-q" for cases such as
"gappy" arma and seasonal arma? Is it just the total number of AR and MA
coefficients estimated?
Yes, AFAICS that's the idea. I'm saying "AFAICS" because given the
lagged endogenous terms in an ARMA model I have never really understood
why this Q test should be used rather than an LM-type test. But that's a
different discussion I guess.
(BTW I'm not sure what you mean by seasonal ARMA or how it differs from
a standard ARMA.)
2) What should we do with our current table of results, which shows ACF,
PACF, Q statistic and p-value from m = 1 up to a specified maximum lag?
Obviously we can't show a p-value when the df is < 0. Should we suppress
all of the rows until m is large enough that df > 0, or just not print Q
+ p-value for the initial rows?
FWIW Eviews used to not print p-values for the first lags I think, but
maybe that has changed.
If I'm not mistaken these Portmanteau type of tests do not only require
large T but also large m (max lag considered). So the whole business
becomes even murkier when m is so small that m-p-q becomes negative.
Also using dof=m instead of m-p-q is not wrong asymptotically I believe,
it's all "just" about small-sample corrections (which can be very
important of course though).
thanks,
sven
5:13 p.m.
On Tue, 3 Mar 2015, Sven Schreiber wrote:
Am 03.03.2015 um 16:05 schrieb Allin Cottrell:
>
> I was thinking along the same lines as in your patch for library.c in
> the GUI, but it's not that simple. Two things have to be answered.
>
> 1) What's the appropriate generalization of "m-p-q" for cases such as
> "gappy" arma and seasonal arma? Is it just the total number of AR and MA
> coefficients estimated?
Yes, AFAICS that's the idea. I'm saying "AFAICS" because given the
lagged
endogenous terms in an ARMA model I have never really understood why this Q
test should be used rather than an LM-type test. But that's a different
discussion I guess.
Well, the vague idea is that, although exact ML estimates don't satisfy
this exactly, the first-order conditions for ML force a few
autocorrelations to be 0 by construction: for example, think of a MA(1)
model: the FOC is simply \sum u_t u_{t-1} = 0 (well, not exactly, but you
get the idea). So, in terms of "moment conditions", this is not a valid
one you can use when you contruct a test statistic and therefore you
should drop it.
The problem is that this reasoning becomes messy when you have mixed AR/MA
models, especially with gaps in the lag structure.
(BTW I'm not sure what you mean by seasonal ARMA or how it
differs from a
standard ARMA.)
A seasonal ARMA is "gappy" by construction.
-------------------------------------------------------
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
-------------------------------------------------------
5:59 p.m.
On 03/03/15 17:31, Sven Schreiber wrote:
FWIW Eviews used to not print p-values for the first lags I think, but
maybe that has changed.
If I'm not mistaken these Portmanteau type of tests do not only
require large T but also large m (max lag considered).
In most practical cases no, I think this is not true. m has to be large
enough to have a sense (including the relevant correlations) but not
very large because this may imply very low power.
So the whole business becomes even murkier when m is so small that
m-p-q becomes negative. Also using dof=m instead of m-p-q is not wrong
asymptotically I believe, it's all "just" about small-sample
corrections (which can be very important of course though).
If your T is very very
large you may calculate the Q stat for a very
large m, and then given p and q not very large, a chi-square(m) and
chi-square (m-p-q) may be similar. But usually we don't have so large T
and we are interested in relatively low values of m. From m>p+q we have
enough dof and the Q stat for a residuals series may have sense, and
the asymptotic distribution is chi-square (m-p-q) different from the
chi-square(m).
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.eus <mailto:ignacio.diaz-emparanza@ehu.eus>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ehu.eus/es/web/ea3* <http://www.ehu.eus/es/web/ea3>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
8:51 a.m.
Am 03.03.2015 um 18:59 schrieb Ignacio Diaz-Emparanza:
On 03/03/15 17:31, Sven Schreiber wrote:
> If I'm not mistaken these Portmanteau type of tests do not
only
> require large T but also large m (max lag considered).
In most practical cases no, I think this is not true. m has to be large
enough to have a sense (including the relevant correlations) but not
very large because this may imply very low power.
Yes I know, but I was talking about the asymptotic argument.
> So the whole business becomes even murkier when m is so small that
> m-p-q becomes negative. Also using dof=m instead of m-p-q is not wrong
> asymptotically I believe, it's all "just" about small-sample
> corrections (which can be very important of course though).
If your T is very very large you may calculate the Q stat for a very
large m, and then given p and q not very large, a chi-square(m) and
chi-square (m-p-q) may be similar. But usually we don't have so large T
and we are interested in relatively low values of m. From m>p+q we have
enough dof and the Q stat for a residuals series may have sense, and
the asymptotic distribution is chi-square (m-p-q) different from the
chi-square(m).
I'm tempted to dive into the details, but not now; let me just say that
this whole discussion has not weakened my skepticism about using the
Q-type tests for residuals (as opposed to raw original series).
thanks,
sven
9:31 a.m.
On Wed, 4 Mar 2015, Sven Schreiber wrote:
>> So the whole business becomes even murkier when m is so small
that
>> m-p-q becomes negative. Also using dof=m instead of m-p-q is not wrong
>> asymptotically I believe, it's all "just" about small-sample
>> corrections (which can be very important of course though).
> If your T is very very large you may calculate the Q stat for a very
> large m, and then given p and q not very large, a chi-square(m) and
> chi-square (m-p-q) may be similar. But usually we don't have so large T
> and we are interested in relatively low values of m. From m>p+q we have
> enough dof and the Q stat for a residuals series may have sense, and
> the asymptotic distribution is chi-square (m-p-q) different from the
> chi-square(m).
I'm tempted to dive into the details, but not now; let me just say that this
whole discussion has not weakened my skepticism about using the Q-type tests
for residuals (as opposed to raw original series).
At the risk of being boring, let me say: I believe the only solid way to
analyse the issue is to view the Q statistic as a conditional moment test.
I'd love to go into greater detail, but I have to run to class (to
paraphrase Pierre de fermat).
-------------------------------------------------------
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
-------------------------------------------------------
3581
days inactive
3582
days old
13 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber