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