search

mhallsmoore / qstrader

QuantStart.com - QSTrader backtesting simulation engine.
https://www.quantstart.com/qstrader/
MIT License
2.94k stars 854 forks source link

Feature: Backtesting with IB data #11

Closed ryankennedyio closed 8 years ago

ryankennedyio commented 8 years ago

Working on this at the moment as a feature, using swigibpy, on my branch here:

https://github.com/ryankennedyio/qstrader/tree/ibgateway

Just gone around setting up a new price_handler for this feature. Will also set up a new execution_handler for this as well.

Will need to update README.md with instructions for swigibpy setup V0.5.0 and IB Gateway setup too.

Believe that live data ("paper traded" to begin with) will require a new price_handler again because IB doesn't let us "stream" historic ticks?

I only have access to IB Demo account for the next ~4 weeks (data is useless in demo acct), so won't do much more than the bare basics.

mhallsmoore commented 8 years ago

Hi Ryan,

Thanks a lot for this! I'll take a good look at it and get back to you.

Firstly, we should definitely add significant testing to the code (I'm not sure if you've done this yet) and we can come up with some unit test specifications together.

I'll add swigibpy to the requirements.txt once we're both happy with the code, and of course instructions for IB Gateway. This will obviously be platform dependent.

As for the demo account, we don't need to worry about this too much as, going forward, I'll have access to a paper-trading account we can use.

ryankennedyio commented 8 years ago

Not a problem. Unit testing is complete on the Strategy component, but haven't done anything with my IBPriceHandler yet as it's still pretty rough (just getting things working and settling on the "right" approach).

I don't believe unit testing code around swigibpy or the IB components would be too useful since most of the logic is abstracted away from QStrader, so I think integration tests would be a lot more suitable, with mocks set up for the swigibpy functions used. That way we can test the full coverage of expected result from the API really quickly, but it does require a bit more leg work around mocking swigibpy up.

On a semi related historic/data-feed note; I'm tossing up a few different market data providers at the moment (IB market data sounds a bit meh for a few reasons), so I might personally end up using a ZeroMQ-based Price Handler that reads ticks which have been emitted from a separate C program acting as a stock screener. The C program would either feed ticks in from a HDF5 DB or emit them from the realtime stream. C program can then emit raw ticks, or roll them up into OCHLV bars if required before emitting them. Main reason is that my preferred (at this stage) data provider only has a C API, and the stock-screening/tick-rolling computation might be more suited to C if I'm watching a large universe of stocks.

QStrader wouldn't need to know where they're from, which is neat, so my personal stuff is abstracted away nicely from the rest of the system. I'm not sure how you're envisioning incorporating a historic DB into the QStrader, but that's roughly the architecture I'll probably personally go with if this provider is all it's cracked up to be.

This also handles the needs of a stock-screener for me personally -- not sure how you'd plan or prefer to do stock-screening, but that's a separate topic entirely