From ripley at stats.ox.ac.uk  Tue Apr 17 18:01:29 2007
From: ripley at stats.ox.ac.uk (ripley at stats.ox.ac.uk)
Date: Tue, 17 Apr 2007 18:01:29 +0200 (CEST)
Subject: [Rd] predict.ar() produces wrong SE's (PR#9614)
Message-ID: <20070417160129.824875DE7D@slim.kubism.ku.dk>

Thank you.  Here is a reproducible example (since yours is not of the 
actual code):

example(ar)
predict(sunspot.ar, n.ahead=25)
predict(sunspot.ar, n.ahead=20)

and compare, say, prediction 20.

Fixed for 2.5.0.

On Tue, 17 Apr 2007, kirk.hampel at abs.gov.au wrote:

> Full_Name: Kirk Hampel
> Version: 2.4.1
> OS: Windows
> Submission from: (NULL) (144.53.251.2)
>
>
> Given an AR(p) model, the last p SE's are wrong.
>
> The source of the bug is that the C code (ver 2.4.0) assumes *npsi is the length
> of the psi vector (which is n+p), whilst the predict.ar function in R passes out
> as.integer(npsi), where npsi <- n-1.
>
> Some R code following reproduces the error. Let p=4, n=6, then
>
>> ar<-c(-0.5,0.25,-0.125,0.0625)
>> Mod(polyroot(c(1,-ar))) # ar model is stationary
> [1] 1.037580 2.444163 2.444163 2.581298
>> #Pass in values as predict.ar does
>> cumsum(c(1,.C("artoma",as.integer(4),as.double(ar),double(9),as.integer(5))[[3]][1:5]^2))
> [1] 1.000000 1.250000 1.312500 1.328125 1.332031 1.332031
>> #Pass in value that C code expects
>> cumsum(c(1,.C("artoma",as.integer(4),as.double(ar),double(9),as.integer(9))[[3]][1:5]^2))
> [1] 1.000000 1.250000 1.500000 1.750000 2.000000 2.219727
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] predict.ar() produces wrong SE's (PR#9614)
ripley at stats.ox.ac.uk