From Kurt.Hornik@ci.tuwien.ac.at  Thu Jul 15 17:38:03 1999
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Thu, 15 Jul 1999 18:38:03 +0200 (CEST)
Subject: tseries
In-Reply-To: <199907151604.SAA10786@sophie.ethz.ch>
References: <XFMail.990715163125.plummer@iarc.fr>
 <378DFBF9.FE784F5E@wu-wien.ac.at>
 <199907151604.SAA10786@sophie.ethz.ch>
Message-ID: <14222.3691.526557.34151@balin.ci.tuwien.ac.at>

>>>>> Martin Maechler writes:

> Dear Adrian (and everyone else), to the same topic, I've got a file
> "tseries-comments" five days old that I never got around polishing
> before sending to you :

>>> Thank you very much for the functionality !
>>> 
>>> - tsparam : not the best name for that class.. ???
>>> 
>>> ybnd : should be allowed to have EITHER length 1 of length = length(x)
>>> 
--> my patched version
>>> 
>>> - plot.tsparam: 	use 'type = "h"'  as default!
>>> 
>>> - acf, pacf :
>>> 
>>> are *one* function in S-plus,
>>> 
>>> use 'plot = T', not 'pl = T'  as argument
>>> (in line with several other R functions !)
>>> 
--> other small improvements...
>>> 
>>> {including:  instead of  rep(0, nnn),  use numeric(nnn) }
>>> 
--> my version
>>> [[ I'll send this in private to Adrian ]]

> As you see, 
> some of these 5day old comments are in line with Martyn's 
> (he is Martyn, I am Martin). 

> A few thoughts :

> - Yes, we want to be S(-plus) compatible as long as it is not too hard
>   or there are not good reasons against compatibility.

Agreed.
 
>   Particularly, acf(), spec.pgram(), spectrum(), ar(), ar.yw() should
>   have compatible argument names [at least for the important ones] to
>   make it easy to many users moving from S to R (;-).

Agreed.

> - Of course, it is *the wise thing* to use FFT for acf -- for the case
>   of no NAs.. [and I think the NA case should be handled as well, and
>   for small no-NA series that straightforward method will probably be
>   faster > than FFT as well ].

> - I'd very much appreciate if Martyn and you and Paul G.  (and Brian
>   and Ross and ...  and me, we also have a few improvements on S-plus
>   laying around here) could coordinate to produce ``the real'' time
>   series package for R.

> - As a matter of fact, I hope that some of the functions would become
>   part of "Core R" (such as e.g. "modreg" is base of "Core R"), since
>   e.g., the availability of acf() should not depend on having a
>   contributed package installed on top of "Core R".

Yes, definitely.

> Thanks once more to all the "time series" coders !

What I'd like to see in particular is some work going into model-style
interfaces.  Not sure exactly what it would be like, but something like

   armaxm(y ~ x, orderspecifications)

or maybe even

   armaxm(y ~ A(L) * y + B(L) * e + C(L) * x, ...)

Actually, creating an ARMA model could happen via the parameters or via
fitting data, so here is an extra challenge.

(A comment on tseries:  If possible, I'd prefer to use UC ini style
naming for data sets, such as TreeRing etc.  Name space etc ...)

-k



> Martin Maechler <maechler@stat.math.ethz.ch>	http://stat.ethz.ch/~maechler/
> Seminar fuer Statistik, ETH-Zentrum SOL G1	Sonneggstr.33
> ETH (Federal Inst. Technology)	8092 Zurich	SWITZERLAND
> phone: x-41-1-632-3408		fax: ...-1086			<><
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


tseries
Kurt Hornik