From aim at stats.uwo.ca  Mon Nov 13 20:55:26 2006
From: aim at stats.uwo.ca (A.I. McLeod)
Date: Mon, 13 Nov 2006 14:55:26 -0500
Subject: [Rd] bug in acf (PR#9360) S-Plus Addendum
References: <20061113153014.53F2E572ED@slim.kubism.ku.dk>
	<45589BB1.6050305@stats.uwo.ca>
Message-ID: <000f01c7075d$acd1ebe0$884c6481@stats2.uwo.ca>

Here is the result from S-Plus V.8.
> acf(1,lag.max=1,type="covariance",plot=F)
Call: acf(x = 1, lag.max = 1, type = "covariance", plot = F)

Autocovariances matrix:
  lag X2
1   0  0
2   1  0

Their function does not support the demean option, so the variance is zero but they set 0/0 to 0 instead of 1.  The empty sum is 
zero (that is a standard mathematical convention which S+ follows).  I still think *one* would be better for the correlation at lag 
*zero* since the autocorrelation function at lag *zero* is defined as this in every other case.  As I tried to explain before for 
some algorithms involving the computation of correlations and convolutions, it is more convenient to have this first term (lag zero) 
always set to *one*.  Otherwise it has be treated as a special case as in my GetB function which I showed you.

I guess it is not that important but I think it should be treated as more than a documentation bug!!  Knuth once said that after TeX 
reach Version 3.14 all bugs would just be declared "special features".  That would be another way to handle too.

For "canned data analysis" as opposed to "programming", it really doesn't matter at all how you handle this problem.

Ian McLeod


----- Original Message ----- 
From: "Duncan Murdoch" <murdoch at stats.uwo.ca>
To: <aimcleod at uwo.ca>
Cc: <r-devel at stat.math.ethz.ch>; <R-bugs at biostat.ku.dk>
Sent: Monday, November 13, 2006 11:22 AM
Subject: Re: [Rd] bug in acf (PR#9360)


> On 11/13/2006 10:30 AM, aimcleod at uwo.ca wrote:
>> Full_Name: Ian McLeod
>> Version: 2.3.1
>> OS: Windows
>> Submission from: (NULL) (129.100.76.136)
>>
>>
>>> There is a simple bug in acf as shown below:
>>>
>>> z <- 1
>>> acf(z,lag.max=1,plot=FALSE)
>>> Error in acf(z, lag.max = 1, plot = FALSE) :
>>>        'lag.max' must be at least 1
>>>
>> This is certainly a bug.
>
> I'd say it's a documentation bug, rather than a code bug.
>>
>> There are two problems:
>>
>> (i) the error message is wrong since lag.max is set to 1.  Perhaps, if the
>> function acf can not be used for in this situaiton, a different error message
>> would be more appropriate.  I understand why this might be done but I don't
>> think it is the best approach.
>
> What happens is that lag.max is reduced to length(z)-1, which is zero in your case.  This change should be mentioned in the 
> documentation.
>
>> (ii) Please look at the function GetB which is attached.  This is part a
>> computation for a fast algorithm for exact mle of mean.  Usually phi here are
>> the coefficients from a high order AR but when I tried for AR(1) I got the error
>> message.  So the workaround is given.  Notice that I use: 
>> p*as.vector(acf(phi,lag.max=p,type="covariance",demean=FALSE,plot=FALSE)$acf)
>>
>> so what I expect to get when p=length(phi)=1 is just phi^2.  This is what
>> happens in Mathematica with ListCorrelate[{phi},{phi}].  When you have
>> acf="correlation" and demean=TRUE then one gets 0/0 which should be defined as 1
>> in this situation.
>
> I don't think that's a reasonable expectation.  You've got an empty sum in the formula for the lag 1 autocovariance:
>
> sum_{i=1}^0 phi_i phi_{i+1}
>
> R is assuming that's not what you meant and is reporting it as an error. If it gave you any value, it should be zero, not phi^2.
>
> Duncan Murdoch
>
>>
>> Probably if the R authors just want to use acf for data analysis they may simply
>> choose to require length(x)>1 in acf(x,...) although I don't see the harm in my
>> suggestion either.



[Rd] bug in acf (PR#9360) S-Plus Addendum
A.I. McLeod