On Fri, Apr 8, 2016 at 10:51 AM, James Hirschorn
<james.hirschorn at hotmail.com> wrote:
On 04/06/2016 07:58 PM, Joshua Ulrich wrote:
On Tue, Apr 5, 2016 at 9:17 PM, James Hirschorn <james.hirschorn at hotmail.com> wrote:
OpCl works on xts objects but not on quantmod.OHLC objects. Is this a bug?
Thanks for the minimal, reproducible example. Looks like a bug. There's no as.quantmod.OHLC.xts method, so the zoo method is dispatched. Calling Op() or Cl() on this zoo-based object results in a vector (since zoo will drop dimensions, like a matrix or data.frame), and you can't set column names on a vector. I'm not sure whether it makes more sense to check for dims in all the combination transformations (consisting of combined Op, Hi, Lo, Cl) or to create a as.quantmod.OHLC.xts method. Can you provide some details about your use case?
At this stage, my use case is making some custom indicators. I've not used
quantmod much in the past, but I just assumed that quantmod.OHLC was the
class I should be using with quantmod.
Some details: The starting point was tick data, for example
# n seconds of tick data
n <- 600
tick.data.timestamp <- as.POSIXct("2016-04-06 00:00:00", tz = 'GMT') + 1:n
set.seed(1)
tick.data <- xts(cbind(Price = runif(n, 0, 1),
Volume = sample(1:100, replace = T, n)),
tick.data.timestamp)
Then aggregating to minute OHLC data as quantmod.OHLC:
minute.data <- as.quantmod.OHLC(to.minutes(tick.data),
c("Open","High","Low","Close","Volume"),
name = 'Sym')
or alternatively as xts:
minute.data.xts <- as.xts(minute.data)
OpCl is naturally useful for indicators, since it shows whether we have a
red or green candlestick. xts is working fine for my indicators for now, but
I don't know if not using quantmod.OHLC will be a problem for backtesting.
Using xts should be fine. I'm not sure whether there's much functionality in quantmod that depends on the quantmod.OHLC class.
There are other differences I noticed too. For example, the Lag function (maybe a different bug?): # OK Lag(minute.data)
The result of the above command only has 1 column, though the input data has 5 columns. So it's "OK" in the sense that it doesn't throw an error, but the output is a bit surprising.
# error Lag(minute.data.xts)
Looks like a different bug. The 11x5 matrix is being converted to a 55-element vector, and that vector is used to attempt to create an xts object with an 11-element index.
And lag shifts in the opposite direction!
Yes, that's the default behavior of stats::lag, and zoo::lag.zoo follows that convention for consistency. xts::lag.xts breaks the convention because we thought it was too surprising/confusing to most users (even though it's documented in the *Note* section in ?stats::lag). I recommend you use xts and the lag generic, and avoid using Lag() and quantmod.OHLC objects.
lag(minute.data)[1:4]
Sym.Open Sym.High Sym.Low Sym.Close Sym.Volume 2016-04-06 00:00:59 0.4068302 0.9926841 0.01307758 0.44628435 3133 2016-04-06 00:01:59 0.6401010 0.9918386 0.03554058 0.60530345 2896 2016-04-06 00:02:59 0.9030816 0.9614099 0.04646089 0.42962441 3323 2016-04-06 00:03:59 0.4527201 0.9815635 0.02778712 0.05043966 2657
lag(minute.data.xts)[1:4]
Sym.Open Sym.High Sym.Low Sym.Close Sym.Volume 2016-04-06 00:00:59 NA NA NA NA NA 2016-04-06 00:01:59 0.2655087 0.9919061 0.01339033 0.6620051 3136 2016-04-06 00:02:59 0.4068302 0.9926841 0.01307758 0.4462843 3133 2016-04-06 00:03:59 0.6401010 0.9918386 0.03554058 0.6053034 2896
Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com R/Finance 2016 | www.rinfinance.com