Multiple tickers, with price values in one market event

[mhallsmoore]

A common pattern that I've found in carrying out strategy development, particularly with equity portfolios involving many tickers, is that the AbstractStrategy-derived strategy class must keep a tally of all current prices of each ticker it is interested in. This is particularly problematic for equity portfolios consisting of 30+ tickers.

In particular, for some of my strategies, it must wait to carry out any strategy logic until all ticker closing prices for a particular day have arrived. This means the receipt of N MarketEvent objects.

Rather than sending each individual ticker in a separate market event it might be better to instead create a DailyMarketEvent object (or similar) that provides bar information for all interested tickers in one go, thus reducing the need for boilerplate code living within the strategy class itself that keeps track of prices.

Let me know what you think of this and I'll code up a test to see how it works in practice.

[ryankennedyio]

I think the computational complexity is equivalent either way (i.e. same amount of 'work' must be done), it's just a question of whether the logic should be in the strategy or the event loop.

One thing I know that would help us out with the event loop speed is ensuring that update_portfolio() and statistics.update() only get called at the next timestep, rather than at every new bar.

I think there might be an opportunity to do two birds with one stone there.

[femtotrader]

A priority queue may help https://github.com/femtotrader/femtotrading/blob/master/femtotrading/priority_queue.py

[enriqueromualdez]

Hey all,

Attempting to figure this out now. I am a bit lost on the best approach as so far, what I've come up with might not exactly be the most efficient way of doing things. Is it possible to combineBarEvents into a single BarEvent? Maybe as a list which contains BarEvents that share the same timestamp that can then be iterated over by _run_sessions()?

The problem I see with this approach is of course the fact that _run_sessions() will prioritize whichever Ticker comes up first from the BarEvent list. In order to avoid the Tickers obtaining any priority, wouldn't it make sense to use some multi-threading in order to run calculate_signals() on all Tickers simultaneously?

Thoughts? Ideas?