# Implementing indicators which require OHLC

Home 21090308 Forums Applications Trading Strategies (Algo Quant) Implementing indicators which require OHLC

• This topic is empty.
Viewing 1 post (of 1 total)
• Author
Posts
• #1857
kmika
Member

Good evening QF5205: Algorithmic Trading class,

After exploring the various classes in the Algoquant library, here is what I think about implementing strategies which require OHLC data. Some understanding of the different classes, as given in the [font=Monaco:fy1jlczh]MovingAverage[/font:fy1jlczh] example, is in order first.

1. The over arching objective of all this classes is to get two [font=Monaco:fy1jlczh]DoubleSignals[/font:fy1jlczh] so that they can be put inside the constructor of the [font=Monaco:fy1jlczh]Crossover[/font:fy1jlczh] class. We then let the code in that class do its job of seeing where they cross and buy/sell accordingly. Having said that, the [font=Monaco:fy1jlczh]DoubleSignals[/font:fy1jlczh] represent the moving averages and to a larger extend, the indicators we want for whatever strategies.
2. The [font=Monaco:fy1jlczh]MovingAverageCrossover[/font:fy1jlczh] class is used to create these two [font=Monaco:fy1jlczh]MovingAverages[/font:fy1jlczh], which remember implements [font=Monaco:fy1jlczh]DoubleSignal[/font:fy1jlczh].
3. I would say that the coding for the indicators starts in the [font=Monaco:fy1jlczh]MovingAverage implements DoubleSignal[/font:fy1jlczh] class. In there, you need to deal with classes [font=Monaco:fy1jlczh]Cache[/font:fy1jlczh] and [font=Monaco:fy1jlczh]Filter[/font:fy1jlczh]. (which actually turns out to be easy part in coding OHLC indicators).

With the above understanding, I therefore conclude that when we create a new class for our OHLC indicator, it will indeed be [font=Monaco:fy1jlczh]OHLCIndicator implements DoubleSignal[/font:fy1jlczh] and NOT [font=Monaco:fy1jlczh]OHLCIndicator implements DoubleSignal[/font:fy1jlczh], although the latter is a valid declaration. This is different from what I thought and raised in class before. The reason is because the [font=Monaco:fy1jlczh]OHLCIndicator[/font:fy1jlczh] will be a signal of THE indicator itself, and therefore a double value signal. We are supposed to have used all the OHLC data already.

Thus the problem is how do we get the OHLC data into our [font=Monaco:fy1jlczh]OHLCIndicator implements DoubleSignal[/font:fy1jlczh]. I am still figuring this one out, but here is what I think. It starts with the class method [font=Monaco:fy1jlczh]public synchronized void update(Time t, Double px)[/font:fy1jlczh]. As you can clearly see, only the price [font=Monaco:fy1jlczh]px[/font:fy1jlczh] goes into the update method. We need some way to get the OHLC data into this method.

If you quickly recourse back to where this update method is called, it is called in the [font=Monaco:fy1jlczh]computeOrders(Time time, double price, double position)[/font:fy1jlczh] method which is in the [font=Monaco:fy1jlczh]SMA2Crossover[/font:fy1jlczh] class. Since the [font=Monaco:fy1jlczh]MovingAverage[/font:fy1jlczh] strategy does not need OHLC data, it would make sense to just pass double price down the calling methods.

I suggest, and this is taking quite a bit of risk in changing major parts of the library, to overload the [font=Monaco:fy1jlczh]computeOrders[/font:fy1jlczh] method with a double high and double low argument. This would be a direct way to get the high and low data into the [font=Monaco:fy1jlczh]OHLCIndicator[/font:fy1jlczh] class thereby allowing us to code up our indicator. However, to proceed we need to look at when the [font=Monaco:fy1jlczh]computeOrders[/font:fy1jlczh] is called, which I suspect is in the [font=Monaco:fy1jlczh]Simulator Run[/font:fy1jlczh] method, which in turn is blocked out.

This is the only way I thought of coding up an OHLC indicator, which at very best is nontrivial and requires areas of code not accessible to the user. Any easier solution will be greatly appreciated.

Thanks.
Donny

Viewing 1 post (of 1 total)
• You must be logged in to reply to this topic.