Marcin B. has been in touch with me about providing an accessor or function such that you could retrieve ACF/PACF values for further analysis, and I thought I'd bring this issue to the list.

This could work, but my alternative thought was to provide a function acf() -- or corrgm(), the name doesn't matter much -- that works in a "stand-alone" manner to provide an acf vector. This seemed a little more "natural" to me than using an accessor. Now I take your point that one might also want the partial autocorrelations, or for that matter the cross-correlogram of two variables. We could do this by providing three functions, e.g., acy(y, p) pacf(y, p) xcf(x, y, p) where x and y are series and p is the maximum lag. It would be possible to combine acf and pacf into one function by using a third boolean parameter to distinguish the cases -- or, I suppose, we could have a corrgm() function with returns a p x 2 matrix with the ACF in column 1 and the PACF in column 2. I'm not sure which of these options is best.

On Mon, 26 Jan 2009, Sven Schreiber wrote: > Allin Cottrell schrieb: >> We could do this by providing three functions, e.g., >> >> acy(y, p) >> pacf(y, p) >> xcf(x, y, p) >> >> where x and y are series and p is the maximum lag. It would >> be possible to combine acf and pacf into one function by using >> a third boolean parameter to distinguish the cases... > I have no strong opinions here, but for heavy-duty > number-crunching in simulations I guess it would be better to > only calculate the results that are really needed to save cpu > time. So no automatic returning of both ACF and PACF unless it > is explicitly requested. > > Also, I would be in favor of not introducing too many new > function names for the sake of finding quickly what you want in > the function documentation. So I think having one function, say > 'acf' (but there may be better names), with a parameter that > determines whether you want the standard acf, or pacf, or > cross-correlation. > > In general I would suggest to have only one data argument which > must be either a series, or a list of series, or a matrix... For now, in CVS, we have a compromise between what I originally had in mind and what Sven suggested. I agree that it's good to avoid excessive proliferation of function names, but on the other hand I find heavily overloaded functions kind of confusing. Result: two functions, acf() (which also does pacf, see below) and a separate xcf(). I also agree that it's nice to support as many relevant data types as possible, but such flexibility is complex to arrange so at present it's more limited than Sven indicated. That is, * acf has 2 required arguments: the first can be a series or a matrix, the second, p, must be a scalar (lag order). In addition it has a third optional argument: the word "partial", or any leading portion thereof (just "p" will do), to get the PACF. If the first arg is a series, returns a p-vector; if it's a matrix, returns a p x m matrix where m is the number of columns in the input matrix (i.e. each column is taken as a series). examples/tests: open data9-7 -q corrgm PRIME 12 -q matrix a = acf(PRIME, 12) # series input a matrix x = {PRIME} a = acf(x, 12) # matrix input a corrgm UNEMP 12 -q x = {PRIME,UNEMP} # two-col matrix input a = acf(x, 12) a a = acf(x, 12, partial) a * xcf has three required arguments: the first two may be series or matrices (column vectors only), but must be of the same type. The third scalar argument is the lag order, p. Output is a column vector of length 2*p + 1. open data9-7 -q xcorrgm PRIME UNEMP 6 -q a = xcf(PRIME, UNEMP, 6) a matrix x = {PRIME} matrix y = {UNEMP} a = xcf(x, y, 6) a Allin. _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

We could actually drop the extra boolean parameter by using a trick similar to what we currently do for ADF: p>0 means autocorrelations, p<0 means partial autocorrelations. Or would it be too arcane?

I agree with Sven that we should strive for maximum efficiency. Let's analyse the cases: 1) only ACF needed 2) only PACF needed 3) both needed. Case 2) is a bit unlikely. Even in the (rather exotic) case when these statistics are used as intermediate products in a simulation-based estimator, the PACs are a bijective function of the ACs, so they provide no extra information, from a strictly theoretical point of view. Besides, the algorithm we use for the PACF needs the ACF anyway, so showing just the PACF is a waste of CPU anyway.

A possible compromise could be: if only the ACF is requested, then leave the function the way it is now. Otherwise (via the boolean switch, or the negative parameter, I don't care very much), output a 2*p vector, with the ACF in [1:p] and the PACF in [p+1:2*p]. Again, this may be confusing at first, but hey.

One last thing: IMO it's easy enough to get the periodogram already via fft() (see example 5.4 in the User's Guide), no?

On Mon, 2 Feb 2009, Sven Schreiber wrote: > On 02.02.2009 20:55, Riccardo (Jack) Lucchetti wrote: >> >> We could actually drop the extra boolean parameter by using a >> trick similar to what we currently do for ADF: p>0 means >> autocorrelations, p<0 means partial autocorrelations. Or >> would it be too arcane? > > yes, FWIW I wouldn't like that very much It's no big deal on my side; it was mainly an aesthetic thing: I don't like very much having a string parameter dangling at the end. Also, the positive/negative thing may simplify script writing.

> I don't think case 2 is so unlikely, but if the ACF is > computed anyway then sure you can spit it out as well Yeah, in practice we would have the options "just acf"/"pacf too"

On overloaded functions, I'll just say, think about writing the help entry for the function: if it seems too crazy, give up the idea of overloading...

On Tue, 3 Feb 2009, Allin Cottrell wrote: > On second thoughts, I'm coming round to the idea of a single > function. What about this: > > corrgm(series y, scalar p) -> > p x 2 matrix with ACF and PACF, like the corrgm command > > corrgm(series y1, series y2, scalar p) -> > p x 1 matrix with cross-correlogram I take it you mean 2*p+1 here

> We could accept column vectors in place of series. No proper matrices, then, right?

A possible compromise could be as follows: - arg1 could be either single (series/vector) or multiple (matrix/list). - arg2: scalar, the max order; end of story. - arg3 (optional) could only be is a series/vector. If absent, the function reutrns acf/pacf. If present, the function yields cross-correlations against that variable. Note that in many cases this is all that's required (cfr countless RBC papers which compute cross-covariances _against GDP_). If more is needed, use a loop. Do you like it?

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.)

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, but would involve a good deal of painful tedium (particularly with regard to proper error checking), so not done yet.

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?

> 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.

>> 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.