[Rd] arima.sim problems (PR#3495)

[Prof Brian Ripley]

On Wed, 16 Jul 2003 liang at stat.berkeley.edu wrote:

> Full_Name: Gang Liang
> Version: 1.7.1
> OS: Debian/Woody
> Submission from: (NULL) (192.6.19.190)
> 
> 
> > print(arima.sim(list(ar=.3,order=c(1,1,1)), 30))
>  [1]  0.00000000  0.10734243  0.02907301 -1.23441659 -0.98819317 -2.82731975
>  [7] -2.69052512 -4.22884756 -5.02820635 -5.41514613 -6.20486350 -7.01040649
> [13] -6.78121289 -5.41111810 -4.96338053 -5.42395408 -6.22741444 -5.75228153
> [19] -6.07346580 -7.71726137 -8.16647092 -7.39100567 -6.69696069 -4.77905714
> [25] -1.73530839 -0.19721837  0.08528623  1.43992522  2.59292971  5.05894572
> [31]  6.14539036
> 
> Several problems were found in the above code:
> 
> 1. arima.sim returns a non-ts object when the differencing term is nonzero
>    in the order parameter.

Already fixed in the development version of R.

> 2. there are leading zeros in the simulated sequence again when order[2] is
>    non-zero; therefore, the length of the returned object is not right.

That is intentional.  The leading zeroes are needed to start the series 
off, and they are returned to make clear that is what happened.

> 3. in the above code, I specified the order of ma to be 1, while ma is not
>    given: arima.sim then simply treats ma=0. I don't whether it is a feature
>    or a possible bug. Personally, I think it may be a good idea to enforce
>    certain constraint like: if the order of ma is not zero, then you must
>    provide ma even zero values are fine, but you cannot leave it blank.

You mean to protect against careless users?  Apparently that would be a
good idea and I have just added it.

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