why stream_next() method in price handler only return one ticker data each time ?

[iorilu]

if i put few tickers in tickers list , how to handle this ?

should it return a dict of ticker data ? I am little confused with this.
for each bar event ,I think the strategy calculate_signals function should get all subscribed ticker data

[mhallsmoore]

Hi iorilu,

The original rationale for this was to replicate how events can arrive in a live trading scenario, especially with intraday data being used.

In a backtest it is definitely useful to have access to all market data OHLCV values in a single "event" for any specified tickers, but in live trading, the data won't be received this way (at least for Interactive Brokers).

I actually commented on this problem in a blog post the other day: https://www.quantstart.com/articles/kalman-filter-based-pairs-trading-strategy-in-qstrader

The relevant passages are:

"The next method _set_correct_time_and_price is a 'helper' method utilised to ensure that the Kalman Filter has all of the correct pricing information available at the right point. This is necessary because in an event-driven backtest system such as QSTrader market information arrives sequentially.

We might be in a situation on day K where we've received a price for IEI, but not TFT. Hence we must wait until both TFT and IEI market events have arrived from the backtest loop, through the events queue. In live trading this is not an issue since they will arrive almost instantaneously compared to the trading period of a few days. However, in an event-driven backtest we must wait for both prices to arrive before calculating the new Kalman filter update.

The code essentially checks if the subsequent event is for the current day. If it is, then the correct price is added to the latest_price list of TLT and IEI. If it is a new day then the latest prices are reset and the correct prices are once again added.

This type of 'housekeeping' method will likely be absorbed into the QSTrader codebase in the future, reducing the necessity to write "boilerplate" code, but for now it must form part of the strategy itself."

My main concern is to ensure that any "tricks" utilised to circumvent this issue in backtesting are as near as possible equal to the implementation in live trading, in order to minimise simulation errors.

I'll have a think about this and revert back with some possible ideas in this issue thread.

Mike.