[R-SIG-Finance] filter() on zoo objects

Thu Mar 27 17:18:42 CET 2008

Hi Costas:

I don't think you are using loess correctly - it requires a formula, see ?loess.

with quantmod and xts/zoo:

> getSymbols("^DJI",from='1990-01-01')
[1] "DJI"

> loess(dailyReturn(DJI,type="log") ~ as.numeric(time(DJI)))
Call:
loess(formula = dailyReturn(DJI,type="log") ~ as.numeric(time(DJI)))

Number of Observations: 4595
Equivalent Number of Parameters: 4.34
Residual Standard Error: 0.009854
>

You may need to call Delt(Cl(DJI)) in place of dailyReturn if you
don't have the most recent R-forge version of quantmod.

Additionally filter works too:

> filter(DJI,2)
         [,1]    [,2]    [,3]    [,4]      [,5]    [,6]
 [1,] 5506.40 5623.30 5465.02 5620.30 324140000 5620.30
 [2,] 5620.30 5668.08 5572.52 5619.46 384660000 5619.46
 [3,] 5619.46 5642.92 5532.84 5592.16 354000000 5592.16
 [4,] 5592.16 5620.30 5516.22 5546.50 317060000 5546.50
 [5,]      NA      NA      NA      NA        NA      NA
 [6,]      NA      NA      NA      NA        NA      NA
 [7,] 5546.50 5607.94 5506.82 5588.74 280220000 5588.74
 [8,] 5588.74 5621.58 5520.06 5532.00 310420000 5532.00
 [9,] 5532.00 5545.64 5450.94 5501.28 351980000 5501.28
[10,] 5501.28 5566.54 5496.58 5521.34 308780000 5521.34
...
> as.xts(filter(DJI,2))

1990-01-02 5506.40 5623.30 5465.02 5620.30 324140000 5620.30
1990-01-03 5620.30 5668.08 5572.52 5619.46 384660000 5619.46
1990-01-04 5619.46 5642.92 5532.84 5592.16 354000000 5592.16
1990-01-05 5592.16 5620.30 5516.22 5546.50 317060000 5546.50
1990-01-06      NA      NA      NA      NA        NA      NA
1990-01-07      NA      NA      NA      NA        NA      NA
1990-01-08 5546.50 5607.94 5506.82 5588.74 280220000 5588.74
1990-01-09 5588.74 5621.58 5520.06 5532.00 310420000 5532.00
1990-01-10 5532.00 5545.64 5450.94 5501.28 351980000 5501.28
1990-01-11 5501.28 5566.54 5496.58 5521.34 308780000 5521.34
...

My opinion on the conversion is that it is painful and a waste of
development resources.  All of the time-series objects in R exist for
a reason, and many people are accustomed to one class or another.  As
a developer you had to choose which to support and which to add to
your WISHLIST.  Forcing the user to adopt a particular class such as
'ts' or 'timeSeries' is at best unappealing, and most likely will
simply force the user to look elsewhere for a solution.

The general problem with conversion/reconversion is what we have been
addressing with the `xts` package.  It has yet to be fully sorted out,
and certainly has yet to see wide adoption by other package
developers, but the core concept is simple, and it _is_ implemented so
far in a few functions:

Basically, functions can call `as.xts` on any incoming
time-series-like object, handle it with all the tools available to
zoo/xts objects, and then simply call `reclass` to convert the object
back to its original class to return to the user the class of object
he used in the original call.  There are some minor things to keep
track of if very different objects are returned, but for the most part
it is that simple.

If the object need not be returned then the process truly only
requires a call to 'as.xts' at the beginning.  The rest of the
function can now handle the data as a zoo/xts object.  The majority of
functions seem to only need this approach.

At present you can see 'reclass' in the `to.period` function in `xts`,
as well as the `periodReturn` function that is in the quantmod version
on R-forge.  'as.xts' is used in many functions in both packages to
allow for maximum time-series-like class support - including
chartSeries from quantmod.

The issue that this approach addresses is the simplified and uniform
handling of all of R's disparate time-series-like objects.  `xts`
attempts to handle the conversion and reconversion without having the
package/function author write methods for each class of object.  It
saves time, and makes for a far less error-filled final product.  In
reality it also means that new functions will *just work* with almost
any object that is passed in.

I am working on putting together a vignette to address developing
functions, as well as modifying current ones, with xts.  I will make
it known to the list when it is complete.

Jeff

On Thu, Mar 27, 2008 at 5:17 AM, Vorlow Constantinos
<CVorlow at eurobank.gr> wrote:
> Dear all,
>
>  Am I right in understanding you cannot directly apply functions such as
>  loess() (filter() as well ?) to zoo objects and you need to use the
>  rollapply/rollmean functions instead?
>
>  For example:
>
>  library("tseries")
>  DJ<- get.hist.quote("^DJI", start = "1990-01-01", quote = "Close")
>  DJret<-diff(log(DJ))
>
>  # the
>
>  loess(DJret, time(DJret))
>
>  does not work(?). What am I understanding  wrong? I found a reply by
>  Achim on a similar issue.
>
>  http://finzi.psych.upenn.edu/R/Rhelp02a/archive/88599.html
>
>  Is Achim's answer all there is to it?
>
>  I.e., my problem is a little bit  more general:
>
>  Say I want to produce fits and then forecasts on a time series (zoo
>  mostly) using a non-zoo routine which "understands" ts or timeSeries
>  objects (or simple vectors).  Do I always have to "translate" zoo
>  objects to vectors or to ts/simeSeries ones, run the routines and then
>  put back the zoo attribute with the appropriate dates so as to produce
>  correct time-series plots (with dates etc, especially correct dates
>  alligned to the forecast period - which could be postsample)?
>
>  Is there an easier way to shift between zoo-ts/timeSeries objects and
>  produce plots statistical analysis that will have the dates correctly
>  aligned on (to account for example for irregularly sampled sequences
>  such as stock prices with non-trading days etc. etc.)?
>
>  Thanks in advance,
>  Costas
>
>
>
>  P Think before you print.
>
>  Disclaimer:
>  This e-mail is confidential. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete the copy from your system.
>  EFG Eurobank Ergasias S.A. is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.
>  EFG Eurobank Ergasias S.A. cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. If you suspect that the message may have been intercepted or amended, please call the sender.
>
>
>         [[alternative HTML version deleted]]
>
>  _______________________________________________
>  R-SIG-Finance at stat.math.ethz.ch mailing list
>  https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>  -- Subscriber-posting only.
>  -- If you want to post, subscribe first.
>

-- 
There's a way to do it better - find it.
Thomas A. Edison