Re: [Gretl-devel] Problem with Ljung-Box Q pvalues
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