Re: [Gretl-devel] Getting ACF/PACF/XCF as a matrix
Allin Cottrell schrieb:
On Wed, 4 Feb 2009, Riccardo (Jack) Lucchetti wrote:
> On Tue, 3 Feb 2009, Allin Cottrell wrote:
>
>> It's now implemented in CVS, up to a point. Note that the old CVS
>> functions acf() and xcf() are gone. We now have one function,
>> corrgm(). This has the semantics Jack describes. Absent the
>> third argument, ACF and PACF are combined, in adjacent pairs of
>> columns in the output matrix. (There's just one pair of columns
>> in the output if arg1 is a series or column vector, but k >= 1
>> pairs if arg1 is a general matrix or list.)
> Two possible (mututally exclusive) refinements: one is implied by the
> attached patch: when arg1 is multiple, the 2*n columns of the output
> vector are sorted so that the first n columns contain the ACFs and columns
> from n+1 to 2*n contain the PACFs. This would make it easier (IMO) to
> retrieve the results.
I'm OK with that -- any other reactions?
Yes I think separating ACF and PACF is better, although either would be
fine with me.
> Alternatively (but this is more complex to code and arguably less
> intuitive), we may exploit the 3rd argument like we do with mols() for
> residuals: corrgm() would always return the ACFs in a p \times n matrix.
> If the partial autocorrelations are wanted too, you use a pointer to a
> matrix...
Quite nice, but then I think we'd need two functions again. Too
confusing to have such an overloaded third argument for a single
function.
I agree.
>> The "up to a point" bit is that when the third
argument is given
>> (i.e. cross-correlogram is wanted), only the following two cases
>> are implemented so far:
>>
>> * arg1 = series, arg3 = series
>> * arg1 = column vector, arg3 = column vector
>>
>> Implementing the remaining cross-cases (general matrix or list for
>> arg1; mixed data types between arg1 and arg3) would be nice...
This is now done in CVS.
I was going to say there is no need for that. I tend to think that it
somehow would be cleaner programming practice to not mix series/lists
with matrices, and gretl might as well enforce that.
BTW, if I understand correctly, all the actual calculation code was
already there, so there's no need to worry about the way missing values
are handled, right? But for the mixed series/matrix case which was not
possible before it's not obvious to me how that would handle missing values.
cheers,
sven