xts() speed on data with date index

I like xts because  subsetting is easier.  Something like x["2009-08"].
But it seems that xts() is a little slower than zoo() when converting
data with date index instead of time index.
pr<-matrix(rnorm(20000),nrow=5000,ncol=4)
t<-Sys.time()+(1:5000)*24*3600
d<-as.Date(t)
system.time(x<-zoo(pr,t))
user  system elapsed
      0       0       0
system.time(x<-zoo(pr,d))
user  system elapsed
      0       0       0
system.time(x<-xts(pr,t))
user  system elapsed
      0       0       0
system.time(x<-xts(pr,d))
user  system elapsed
   0.34    0.00    0.35

Regards,
Michael
The explanation for the time difference is likely that xts
converts all time indexes to POSIXct internally whereas
zoo works with them in their original form.   Thus the
time difference would be expected to be the conversion time.

Once its converted then xts would likely be faster for those
xts operatoins where the xts code is in C.  In contrast zoo
is 100% R although eventually it is anticipated that portions
of zoo will be in C too.

As xts in a subclass of zoo some of its operations are done
in zoo so in that case there would not be much of a difference
in speed or if xts handles the corresponding operation itself
but in R then it would not be expected that there would be
much difference either.
I like xts because ?subsetting is easier. ?Something like x["2009-08"].
But it seems that xts() is a little slower than zoo() when converting
data with date index instead of time index.

pr<-matrix(rnorm(20000),nrow=5000,ncol=4)
t<-Sys.time()+(1:5000)*24*3600
d<-as.Date(t)
system.time(x<-zoo(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-zoo(pr,d))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,d))
? user ?system elapsed
? 0.34 ? ?0.00 ? ?0.35

Regards,
Michael

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

Gabor is correct.

In addition the operation you are looking at is the creation of an xts
object, which is usually happening once during typical use (or at
least far fewer times than other operations).

xts stores all times internally as POSIXct, for internal
efficiency/consistency purposes. The original time class is preserved
in an internal attribute that is used in calls where it makes sense to
convert for the user:

(1)index():
where you are extracting the 'original' index.  Transparently the
POSIXct is converted back to the time class you expect.  This carries
overhead, but again should be only occasionally used.  Direct access
to the index is via .index()

(2)print() or printing by default.
Conversion cost is irrelevant here, as it is assumed you will spend
far more time looking at the output than any cost to convert.

The logic is that everything is 'time', just with slightly different
internal representations.  The user shouldn't have to care about time
choice, just as the user should have to care about big-endian or
little-endian hardware storage.

There are some technical issues that are still not perfect of course.
Timezone handling can get tricky if you do a lot of strange subsetting
with *different* index classes.  This type of handling is entirely
impossible in most other time series classes, so the 'weakness' isn't
really valid, as it is still better than most, but it isn't perfect
... yet.

HTH
Jeff

On Sat, Jul 25, 2009 at 8:19 AM, Gabor
The explanation for the time difference is likely that xts
converts all time indexes to POSIXct internally whereas
zoo works with them in their original form. ? Thus the
time difference would be expected to be the conversion time.

Once its converted then xts would likely be faster for those
xts operatoins where the xts code is in C. ?In contrast zoo
is 100% R although eventually it is anticipated that portions
of zoo will be in C too.

As xts in a subclass of zoo some of its operations are done
in zoo so in that case there would not be much of a difference
in speed or if xts handles the corresponding operation itself
but in R then it would not be expected that there would be
much difference either.

On Sat, Jul 25, 2009 at 8:59 AM, michael li<michaellibeijing at gmail.com> wrote:
I like xts because ?subsetting is easier. ?Something like x["2009-08"].
But it seems that xts() is a little slower than zoo() when converting
data with date index instead of time index.

pr<-matrix(rnorm(20000),nrow=5000,ncol=4)
t<-Sys.time()+(1:5000)*24*3600
d<-as.Date(t)
system.time(x<-zoo(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-zoo(pr,d))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,d))
? user ?system elapsed
? 0.34 ? ?0.00 ? ?0.35

Regards,
Michael

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

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

Jeffrey Ryan
jeffrey.ryan at insightalgo.com

ia: insight algorithmics
www.insightalgo.com
An example to clarify/confuse ;)
system.time(px<-xts(pr,t))
user  system elapsed
  0.001   0.001   0.002
system.time(dx<-xts(pr,d))
user  system elapsed
  0.164   0.004   0.168
indexClass(dx)
[1] "Date"
indexClass(px)
[1] "POSIXt"  "POSIXct"

##  in POSIXct time as expected
head(px)
[,1]       [,2]       [,3]       [,4]
2009-07-26 09:39:32  0.6739000  0.6124116 -0.5820407  0.1022264
2009-07-27 09:39:32 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 09:39:32  1.0275375 -0.8538655 -0.6098992  1.9661175
2009-07-29 09:39:32  0.6268532 -0.3144514  1.0142005 -0.2303953
2009-07-30 09:39:32 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 09:39:32 -1.1192617 -0.6575085 -0.9918533 -0.8743504
head(dx)
[,1]       [,2]       [,3]       [,4]
2009-07-26  0.6739000  0.6124116 -0.5820407  0.1022264
2009-07-27 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28  1.0275375 -0.8538655 -0.6098992  1.9661175
2009-07-29  0.6268532 -0.3144514  1.0142005 -0.2303953
2009-07-30 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 -1.1192617 -0.6575085 -0.9918533 -0.8743504
indexClass(px) <- "Date"
### simply convert the indexClass -- this is essentially costless,
### and now you have an xts object 'indexed' by Date
head(px)
[,1]       [,2]       [,3]       [,4]
2009-07-26  0.6739000  0.6124116 -0.5820407  0.1022264
2009-07-27 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28  1.0275375 -0.8538655 -0.6098992  1.9661175
2009-07-29  0.6268532 -0.3144514  1.0142005 -0.2303953
2009-07-30 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 -1.1192617 -0.6575085 -0.9918533 -0.8743504
system.time(indexClass(px) <- "Date")
user  system elapsed
  0.001   0.001   0.001

Now convert back, and see if something like merge cares about the
index class... (hint: it doesn't)
system.time(indexClass(px) <- c("POSIXt","POSIXct"))
user  system elapsed
  0.001   0.000   0.000
indexClass(px)
[1] "POSIXt"  "POSIXct"
head(px)
[,1]       [,2]       [,3]       [,4]
2009-07-26 09:39:32  0.6739000  0.6124116 -0.5820407  0.1022264
2009-07-27 09:39:32 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 09:39:32  1.0275375 -0.8538655 -0.6098992  1.9661175
2009-07-29 09:39:32  0.6268532 -0.3144514  1.0142005 -0.2303953
2009-07-30 09:39:32 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 09:39:32 -1.1192617 -0.6575085 -0.9918533 -0.8743504
head(dx)
[,1]       [,2]       [,3]       [,4]
2009-07-26  0.6739000  0.6124116 -0.5820407  0.1022264
2009-07-27 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28  1.0275375 -0.8538655 -0.6098992  1.9661175
2009-07-29  0.6268532 -0.3144514  1.0142005 -0.2303953
2009-07-30 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 -1.1192617 -0.6575085 -0.9918533 -0.8743504
system.time(merge(dx,dx))
user  system elapsed
  0.001   0.000   0.002
system.time(merge(px,px))
user  system elapsed
  0.001   0.000   0.002

### Caveat: converting back and forth is a bit silly, and possibly
perilous, but it is
### illustrative of what you can do with xts

HTHsomewhat

Jeff
I like xts because ?subsetting is easier. ?Something like x["2009-08"].
But it seems that xts() is a little slower than zoo() when converting
data with date index instead of time index.

pr<-matrix(rnorm(20000),nrow=5000,ncol=4)
t<-Sys.time()+(1:5000)*24*3600
d<-as.Date(t)
system.time(x<-zoo(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-zoo(pr,d))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,d))
? user ?system elapsed
? 0.34 ? ?0.00 ? ?0.35

Regards,
Michael

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

Jeffrey Ryan
jeffrey.ryan at insightalgo.com

ia: insight algorithmics
www.insightalgo.com
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20090726/eb3fe18c/attachment.pl>
The conversion to or from Date occurs when you store it (as you
noticed) or print it out or otherwise try to use it in a context that
requires a Date.  Your example does not do any of those so no
conversion was needed.  Try this:
system.time(print(x))
...
   user  system elapsed
   0.39    0.00    0.39
system.time(print(t))
...
   user  system elapsed
   0.08    0.00    0.11
Thanks for detailed explanation and demo codes.indexClass(x)<-"Date ?is
great for its speed. ? And easier than ?as.Date(x). ? as.Date(x) ?will
change the date to UTC for POSIXct automatically no matter whether you like
it or not. ? It seems indexClass(x)<-"Date will not change the time zone of
the date, which is exactly what I need.
The following codes meet my needs exactly with high speed.
library(quantmod)

pr<-matrix(rnorm(20000),nrow=5000,ncol=4)
t<-Sys.time()+(1:5000)*24*3600
system.time(x<-xts(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
head(x)
? ? ? ? ? ? ? ? ? ? ? ? ?[,1] ? ? ? [,2] ? ? ? ?[,3] ? ? ? ?[,4]
2009-07-27 09:35:39 ?0.6735081 -2.0724029 -2.36234114 -0.74839095
2009-07-28 09:35:39 -1.7756642 ?0.7624485 -2.15179721 -0.98905882
2009-07-29 09:35:39 ?1.2053857 -1.5182344 ?0.12540278 -0.02926681
2009-07-30 09:35:39 -0.5301832 ?0.3087448 -0.46227937 -1.03176589
2009-07-31 09:35:39 -0.9061220 ?1.2160150 -0.85206307 -1.13925796
2009-08-01 09:35:39 -0.2954440 ?0.7048516 ?0.03260057 ?2.04602758
system.time(indexClass(x)<- "Date")
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
head(x)
? ? ? ? ? ? ? ? [,1] ? ? ? [,2] ? ? ? ?[,3] ? ? ? ?[,4]
2009-07-27 ?0.6735081 -2.0724029 -2.36234114 -0.74839095
2009-07-28 -1.7756642 ?0.7624485 -2.15179721 -0.98905882
2009-07-29 ?1.2053857 -1.5182344 ?0.12540278 -0.02926681
2009-07-30 -0.5301832 ?0.3087448 -0.46227937 -1.03176589
2009-07-31 -0.9061220 ?1.2160150 -0.85206307 -1.13925796
2009-08-01 -0.2954440 ?0.7048516 ?0.03260057 ?2.04602758

Thanks Jeff and Gabor.

Michael

On Sat, Jul 25, 2009 at 10:46 PM, Jeff Ryan <jeff.a.ryan at gmail.com> wrote:

An example to clarify/confuse ;)

system.time(px<-xts(pr,t))
? user ?system elapsed
?0.001 ? 0.001 ? 0.002
system.time(dx<-xts(pr,d))
? user ?system elapsed
?0.164 ? 0.004 ? 0.168
indexClass(dx)
[1] "Date"
indexClass(px)
[1] "POSIXt" ?"POSIXct"

## ?in POSIXct time as expected
head(px)
? ? ? ? ? ? ? ? ? ? ? ? ?[,1] ? ? ? [,2] ? ? ? [,3] ? ? ? [,4]
2009-07-26 09:39:32 ?0.6739000 ?0.6124116 -0.5820407 ?0.1022264
2009-07-27 09:39:32 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 09:39:32 ?1.0275375 -0.8538655 -0.6098992 ?1.9661175
2009-07-29 09:39:32 ?0.6268532 -0.3144514 ?1.0142005 -0.2303953
2009-07-30 09:39:32 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 09:39:32 -1.1192617 -0.6575085 -0.9918533 -0.8743504

head(dx)
? ? ? ? ? ? ? ? [,1] ? ? ? [,2] ? ? ? [,3] ? ? ? [,4]
2009-07-26 ?0.6739000 ?0.6124116 -0.5820407 ?0.1022264
2009-07-27 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 ?1.0275375 -0.8538655 -0.6098992 ?1.9661175
2009-07-29 ?0.6268532 -0.3144514 ?1.0142005 -0.2303953
2009-07-30 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 -1.1192617 -0.6575085 -0.9918533 -0.8743504
indexClass(px) <- "Date"
### simply convert the indexClass -- this is essentially costless,
### and now you have an xts object 'indexed' by Date
head(px)
? ? ? ? ? ? ? ? [,1] ? ? ? [,2] ? ? ? [,3] ? ? ? [,4]
2009-07-26 ?0.6739000 ?0.6124116 -0.5820407 ?0.1022264
2009-07-27 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 ?1.0275375 -0.8538655 -0.6098992 ?1.9661175
2009-07-29 ?0.6268532 -0.3144514 ?1.0142005 -0.2303953
2009-07-30 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 -1.1192617 -0.6575085 -0.9918533 -0.8743504
system.time(indexClass(px) <- "Date")
? user ?system elapsed
?0.001 ? 0.001 ? 0.001

Now convert back, and see if something like merge cares about the
index class... (hint: it doesn't)

system.time(indexClass(px) <- c("POSIXt","POSIXct"))
? user ?system elapsed
?0.001 ? 0.000 ? 0.000
indexClass(px)
[1] "POSIXt" ?"POSIXct"
head(px)
? ? ? ? ? ? ? ? ? ? ? ? ?[,1] ? ? ? [,2] ? ? ? [,3] ? ? ? [,4]
2009-07-26 09:39:32 ?0.6739000 ?0.6124116 -0.5820407 ?0.1022264
2009-07-27 09:39:32 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 09:39:32 ?1.0275375 -0.8538655 -0.6098992 ?1.9661175
2009-07-29 09:39:32 ?0.6268532 -0.3144514 ?1.0142005 -0.2303953
2009-07-30 09:39:32 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 09:39:32 -1.1192617 -0.6575085 -0.9918533 -0.8743504
head(dx)
? ? ? ? ? ? ? ? [,1] ? ? ? [,2] ? ? ? [,3] ? ? ? [,4]
2009-07-26 ?0.6739000 ?0.6124116 -0.5820407 ?0.1022264
2009-07-27 -0.7806308 -0.4988508 -0.5448239 -0.5649892
2009-07-28 ?1.0275375 -0.8538655 -0.6098992 ?1.9661175
2009-07-29 ?0.6268532 -0.3144514 ?1.0142005 -0.2303953
2009-07-30 -3.8062200 -0.3875341 -0.9251609 -0.4677076
2009-07-31 -1.1192617 -0.6575085 -0.9918533 -0.8743504
system.time(merge(dx,dx))
? user ?system elapsed
?0.001 ? 0.000 ? 0.002
system.time(merge(px,px))
? user ?system elapsed
?0.001 ? 0.000 ? 0.002

### Caveat: converting back and forth is a bit silly, and possibly
perilous, but it is
### illustrative of what you can do with xts

HTHsomewhat

Jeff

On Sat, Jul 25, 2009 at 7:59 AM, michael li<michaellibeijing at gmail.com>
wrote:
I like xts because ?subsetting is easier. ?Something like x["2009-08"].
But it seems that xts() is a little slower than zoo() when converting
data with date index instead of time index.

pr<-matrix(rnorm(20000),nrow=5000,ncol=4)
t<-Sys.time()+(1:5000)*24*3600
d<-as.Date(t)
system.time(x<-zoo(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-zoo(pr,d))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,t))
? user ?system elapsed
? ? ?0 ? ? ? 0 ? ? ? 0
system.time(x<-xts(pr,d))
? user ?system elapsed
? 0.34 ? ?0.00 ? ?0.35

Regards,
Michael

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

--
Jeffrey Ryan
jeffrey.ryan at insightalgo.com

ia: insight algorithmics
www.insightalgo.com

? ? ? ?[[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.

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20090726/0c510444/attachment.pl>
Dear all

I?m facing the problem of valuing a tier 1 Bond. The Bond has an  
embedded option which allows no coupon payment if the issuer doesn?t  
pay dividends.

Does anybody have an idea how I could model this type of Bond? Please  
let me know if you have a model or a replicating method.

Many thanks in advance and best regards,
Roger
Hi,
  I noticed that the periodReturn function seems to a take non-trivial
amount of time to compute weekly returns. 

  The calls below all compute the log returns from 1/1/2007 to now and
they take slightly different amounts of time.

  I'd like to be able to compute weekly returns as fast as possible.
Does anyone have suggestions for minimizing the processing time?
Different data type?  Different function to call?  

Thanks,
Ian
yhoo=getSymbols("GOOG",source="yahoo",from = "01-01-2004")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',
subset="2007::"))
   user  system elapsed 
   0.06    0.00    0.06
yhoo=getSymbols("GOOG",source="yahoo",from = "01-01-2007")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',
subset="2007::"))
   user  system elapsed 
   0.04    0.00    0.07
yhoo=getSymbols("GOOG",source="yahoo")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log'))
user  system elapsed 
   0.05    0.00    0.05
Hi,
  I noticed that the periodReturn function seems to a take non-trivial
amount of time to compute weekly returns. 

  The calls below all compute the log returns from 1/1/2007 to now and
they take slightly different amounts of time.

  I'd like to be able to compute weekly returns as fast as possible.
Does anyone have suggestions for minimizing the processing time?
Different data type?  Different function to call?  

Thanks,
Ian  

yhoo=getSymbols("GOOG",source="yahoo",from = "01-01-2004")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',

subset="2007::"))
   user  system elapsed 
   0.06    0.00    0.06 

yhoo=getSymbols("GOOG",source="yahoo",from = "01-01-2007")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',

subset="2007::"))
   user  system elapsed 
   0.04    0.00    0.07

yhoo=getSymbols("GOOG",source="yahoo")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log'))

   user  system elapsed 
   0.05    0.00    0.05

Ian,

1/20th of a second for WEEKLY aggregated returns on 2+ years of data 
doesn't seem outrageous.  So might gain a tiny bit by calling log() 
directly, but I doubt it.  I could of course be wrong, but the tiny time 
difference seems trivial, not "non-trivial".  Perhaps you need to 
investigate use of foreach and doMC for your larger problem?

Regards,

   - Brian
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
I suspect we live in marginally different worlds - as 0.05 seems
'trivial' to me.

While all this software is "free" I'd like to reiterate that it
actually costs someone (usually) lots of time.

A better/helpful post could include some effort to identify a
bottleneck, or maybe show what you've accomplished to make it better.

The above said, a few suggestions:

In one CPU hour (10 cents on Amazon?) you could do periodReturn 60,000 times.

Assuming an hour to better the performance by 50%, and at a price of
to code of say $100/hr you'd need to plan on using the new function
120,000,000 times.  These estimates are also quite unrealistic..
300,000,000 times might be closer.  That is one heck of a universe of
instruments.

If you find yourself calling the function over and over, saving the
results might be useful too.

Part of the above <rant> was to illustrate that there is no free lunch
--- even in the land of free beer.

That said, periodReturn was meant to be easy to use first, and fast a
distant second.

Try:
t1 <- system.time(weeks2 <- diff(log(Cl(GOOG)[endpoints(GOOG,'weeks')]))['2007/'])
t2 <- system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',subset="2007/"))
(t2/t1)[3]
elapsed
20.71429
all.equal(coredata(weeks),coredata(weeks2),check.attributes=FALSE)
[1] TRUE

The direct route is 20x faster.

As it turns out, I am refactoring the internal to.period code to be
much faster/memory efficient.  The original was Fortran, which while
very fast, suffers from a lot of required copying in R, so the code is
changing (originally from 2007).  I'll probably also think about
making the simple cases use something more along the direct route.

HTH
Jeff
Hi,
?I noticed that the periodReturn function seems to a take non-trivial
amount of time to compute weekly returns.

?The calls below all compute the log returns from 1/1/2007 to now and
they take slightly different amounts of time.

?I'd like to be able to compute weekly returns as fast as possible.
Does anyone have suggestions for minimizing the processing time?
Different data type? ?Different function to call?

Thanks,
Ian

yhoo=getSymbols("GOOG",source="yahoo",from = "01-01-2004")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',
subset="2007::"))
? user ?system elapsed
? 0.06 ? ?0.00 ? ?0.06
yhoo=getSymbols("GOOG",source="yahoo",from = "01-01-2007")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log',
subset="2007::"))
? user ?system elapsed
? 0.04 ? ?0.00 ? ?0.07
yhoo=getSymbols("GOOG",source="yahoo")
system.time(weeks<-periodReturn(GOOG,period="weekly",type='log'))
? user ?system elapsed
? 0.05 ? ?0.00 ? ?0.05

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

Jeffrey Ryan
jeffrey.ryan at insightalgo.com

ia: insight algorithmics
www.insightalgo.com