Feature/discussion: OHCLV Bars?

I’m not sure that IB allows tick-by-tick data in a backtest, and there’s currently no provisioning in qstrader for Volume (but that itself should be pretty easy).

I think it would be useful if the system would “roll up” streamed tick data into OHCLV bars of a particular duration before they are analysed by a Strategy. It wouldn’t make sense to inundate 1hr+ timeframe strategies with loads and loads of tick-data when they only care about checking things over 5m+

Would this be useful & which part of the system should be responsible for doing this? It would make sense to me that a price_handler should do this, and then the TickEvents that go through the main loop would simply be the OHCLV bars, rather than just Ticks.

[ryankennedyio]

Actually one thing I just remembered thinking about a few weeks ago,

I was kinda wondering if TickEvent and BarEvent could both inherit from the same parent, as that might reduce a tiny bit of code repetition in a few places? For example within the backtester loop

Unsure if it’s worth the effort though. Happy to have a play around if you think it could be worth doing.

I imagine you probably went through the same thought process, but it’s probably trickier than it sounds.

[hpsilva]

Just another thing which might be useful for this discussion, that eventually you are not aware of. oanda-trading-environment (@hootnoot) provides with a neat implementation of a “candle factory” API, storage, etc. In one hand it listens to the broker websocket, on the other hand it distributes binned bar information thru an internal web socket (zmq) to as many strategies as desired, and eventually stores it. It might be interesting for you to have a look, as it seems to me is similar to what you are looking for to implement.

On my own application i ended implementing a passive approach just puling data on a fixed time basis ( x second resolution), as i don’t find of use yet to look at tick or bar data in my strategies. Secondly got me wondering about the kind of stress it would put my system subject to by listening to live tick data and act upon it on heavy trading hours.

About data handling inside a strategy, i have done it on an object oriented fashion by instrument like this:

• On strategy initialization, historical data is pulled from the API for each instrument traded, within the necessary range. This means that the system starts to trade immediately rather then waiting to form a data window in case of i.e. moving averages);
• Start listening to live data;
• New incoming observations are added/bootstrapped to data frame;
• Signal check based on new data;
• On signal act as required;
• Rinse and repeat by waiting for next data observation;

Using dataframes it appeals to me, because i can keep only strict data for the required window, or instead to make use of the entire data set for strategy debugging purposes when live or backtesting. Another appealing advantage is that much of the traditional indicators can be computed easily by pandas with few lines of code.

On the other hand it seemed to me that @mhallsmoore used a cleaner approach by just keeping minimal/current data, and iterates thru a dictionary of instruments to be traded. I liked very much this approach, for simplicity and speed, but ended up using the first due to debugging easiness.

I am really keen to know what are your opinions on this one, and what design directions will be taken as quite recently i came thru exactly this design decisions!!

Helio