From maechler at stat.math.ethz.ch  Sat Nov 24 22:41:56 2007
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Sat, 24 Nov 2007 22:41:56 +0100
Subject: [Rd] Bug in package stats function ar() (PR#10459)
In-Reply-To: <474892CF.602@stats.uwo.ca>
References: <20071124010521.AEE0B282EFF7@mail.pubhealth.ku.dk>
	<13926484.post@talk.nabble.com> <474892CF.602@stats.uwo.ca>
Message-ID: <18248.39588.281267.134511@ada-stat.math.ethz.ch>

>>>>> "DM" == Duncan Murdoch <murdoch at stats.uwo.ca>
>>>>>     on Sat, 24 Nov 2007 16:08:31 -0500 writes:

    DM> On 24/11/2007 11:45 AM, Ben Bolker wrote:
    >> 
    >> 
    >> Steven McKinney wrote:
    >>> Full_Name: Steven McKinney Version: 2.6.0 OS: OS X
    >>> Submission from: (NULL) (142.103.207.10)
    >>> 
    >>> 
    >>> 
    >>> Function ar() in package "stats" is showing a quirky
    >>> bug.  Some calls to ar() run to completion, others throw
    >>> an error.
    >>> 
    >>> The bug is reproducible by several people on different
    >>> machines, however, the ar() function itself ends up
    >>> throwing the error sporadically.  Several calls to ar()
    >>> may be necessary to trip the error condition.
    >>> 
    >>> Code to reproduce:
    >>> 
    >>> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,-1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3))
    >>> # ar function res.ar<-ar(x,aic=TRUE,demean=F) # call
    >>> "ar" again and ............
    >>> res.ar<-ar(x,aic=TRUE,demean=F)
    >>> 
    >>> 
    >>> Example output: (Note that on this attempt the first
    >>> call to ar() tripped the error.)
    >>> 
    >>>> x<-ts(c(-0.2052083,-0.3764986,-0.3762448,0.3740089,0.2737568,2.8235722,-
    >>> +
    >>> 1.7783313,0.2728676,-0.3273164),start=c(1978,3),frequency=4,end=c(1980,3))
    >> 
    >> Slightly more detail: in the "eureka" function, in
    >> stats/src/eureka.f, the last element of "vars" in the
    >> return list is bogus and varies among calls; if it comes
    >> out to NaN or NA it triggers the bug.
    >> 
    >> Haven't spent any more time yet tracking this down, but
    >> hope that will save someone a few minutes.

    DM> Thanks, I'll take a look.

I did too.
It seems pretty obvious that we have to require  

      order.max < n.used
i.e.  order.max <= n.used-1
whereas in the current example, order.max == n.used == 9

I have a small fix which solves the problem and seems to pass
make check...

Martin



[Rd] Bug in package stats function ar() (PR#10459)
Martin Maechler