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.

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

Like Sven, I'd like to have a list as the first argument too. I can't see
any technical obstacles to this, but I may be wrong. OTOH, it's easy
enough to do
list X = foo bar baz
a = acf({X}, 10)
For the sake on economising on the namespace, we _may_ want to use acf()
for cross-correlations too: all it takes is endow acf() with an
alternative syntax like xcf() has now, that is acf(x1, x2, 10). Granted,
that would complicate the parsing, but only to an extent. Pseudo code:
if (isseries(arg1)) {
if (isseries(arg2)) {
if (isscalar(arg3)) {
do_xcf;
} else {
error;
}
} else if (isscalar(arg2)) {
if (arg2>0) {
do_acf;
} else {
do_pacf;
}
} else {
error;
}
} else if (ismatrix(arg1) || islist(arg1)) {
if (isscalar(arg2)) {
if (arg2>0) {
do_multi_acf;
} else {
do_multi_pacf;
}
} else {
error;
}
} else {
error;
}
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?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti