Hello Dan,

I'll give paper trading a go when I get the opportunity. In this mode, I am not clear how the code will handle the "events." In backtesting mode, as I understand, the algorithm doesn't actually run on a real-time wall clock...if the algorithm takes longer than a minute to process a bar (or trailing window of bars), no trading time is lost, and the next sequential datetime stamped bar can be processed. However, under paper trading with a live feed, how is the timing handled? Is there a built-in sub-minute time-out? Or have you modified the code to be real-time and event-triggered?

Also, are the data from NxCore buffered/stored? Is it possible to access a trailing window of NxCore data over multiple trading days? Are the backtest data also available under paper trading?

Grant

BTW, when will trailing stops be rolled out? Hopefully before live trading.

Also FX and commodities

Hi Grant - You are right about backtesting not running on a real-time wall clock. What you may have never run into, though, is that if your algorithm takes longer than 50 seconds to process a bar, then the algorithm throws and error and cancels. We've definitely had some backtesters run into that limitation. When it happens, that basically means you need to make your algorithm perform better so that it can complete a handle_data in under 50 seconds. That limitation is enforced in live/papertrading for the obvious reasons! I think that answers your question.

We are storing the NxCore data. Unfortunately, we don't have the same 11-year library; we only have back a few weeks for NxCore. For now, backtesting is going to use the old data source, and paper/live trading is going to use the new data source. I imagine that we'll make backtesting against the NxCore data available in the future, but we haven't decided on a course.

I did check the two sources against each other, of course. They are almost the same, but not quite. Not surprisingly NxCore is "noisier" with some trades being reported that presumably were data-entry mistakes and don't appear in the cleaned source. There are also a few places where a trade is put in the next bar. For instance, in the old source bar 0 has an open, high, low, close and volume of 1000 and bar 1 has a volume of 2000. In the new data source, bar 0 has a volume of 900 and bar 1 has a volume of 2100. It all worked out in the wash, but some 100-share trade was reported in a different minute.

It's all quite fascinating to me how the different data sources all report differently. There is no "truth" in this stuff, no definitionaly correct version of events. Every data source has a slightly different perspective on what happened.

@Suminda I don't have a schedule for trailing stops. They're definitely doable with the tools you have already, but we haven't prioritized getting them as built-in yet. FX and commodities are definitely post live trading. We want to expand the set of tradeable items, but we're focused on getting people to trading US stocks first.

If someone deploys an algo for live-trading, will it run in a snapshot of the quantopian environment as it existed when deployed? Or is there a possibility that an algo that is running live will wake up one morning and throw exceptions due to some new change/bug in the quantopian env?

Great question Simon. The short answer is "the latter" - it is possible that an algo will "wake up" one morning and throw an exception. Keeping a snapshot of the Quantopian environment isn't practical for a number of reasons.

We are working on a number of measures to prevent the "wake up and fail" problem from happening. It's something we've been giving a lot of thought to. Part of it is product maturity - as Quantopian and Zipline get more mature, they're stabilizing. We're having a cluster of "this algo doesn't work" bugs right now, but I think it is directly attributable to us trying to get a bunch of changes in to the system before live trading.

I expect we'll be talking about this more over time and our stability improves.

In a way, the exception case is the easy one, because at least you know something has gone wrong. If an update introduces a change that doesn't break anything, but changes how the algorithm behaves, one might never know... Maybe backtest regressions would help? Or maybe your customers won't care, and I'm just being a worry-wort!

Btw gave paper trading a whirl yesterday. It did not seem to be working . My algorithm logs some stuff on handle_data and nothing logged.

I also have some improvements to suggest :
On the backtest panel
log_output: -We can define log.info and log.warn and every levels but in log output there is no way to filter to get only the logs above a certain level.
- a "end" feature, ie go to the end of the log without having to scroll for ages.

whoa, had forgotten about quantopian for a while. Hope this will be open to canadians when it goes public.

Pre filter / pre processing function to remove bad data will be interesting.

If this function discards the data then there will be no call to handle_data. Developers can have custom logic to see what is sent in and perhaps edit and pass the bar as needed.

@Simon I agree a silent failure would be worse in many ways. We've been working from the beginning so that we'll know whenever we touch something that might change the algorithm results. For instance, changing the logic about how the website works is strongly separated from the logic that runs a backtest. Of course, that still leaves the case where we change the backtest logic on purpose and it has an unexpected result. We have other tests to help minimize that risk.

@Quentin give it another try, and if it doesn't work, tell us at [email protected] so we can figure out what's going wrong.

@Chris the only limit is the brokerage.

@Suminda That type of filtering is very interesting, and very challenging. There's risk of false positives and missed negatives, both.

Dan , seems to be running now.
Now one last question in paper trading are you checking every live trade or bid/ask to check if we would be executed (in case of limit orders) or is it same way as in backtest ie execution only if close of next bar is >= (resp <=) our limit sell (resp limit buy) .

Thanks
Quentin

Quentin, it's the same as in backtests - the exact same engine in both places. I'm sure we'll do more robust methods in the future, but that's the only one we have so far.

Thanks for the heads up.
It's the right way to do it. I'll be able to check tomorrow, if everything is equal in backtest mode to paper trade mode.

Thanks a lot

Dan,
It would be really nice if you offered various interactive brokers order algos. Say if I was a fundamental trader and wanted to fire a basket of orders every morning, it would be great to have this ability.

Could someone please elaborate on how the connectivity to Interactive Brokers works? Are you running an instance of IBGateway for each client and giving it a username/password entered on the site?

Thanks
Nick

Nick, that's exactly what we do. We store your username and account number (encrypted of course) in our database. We do not store your password. When you want to trade an algorithm, we bring up an instance of IB Gateway for you to use. We pass your user information to the gateway. We prompt you, in the Quantopian website, for your password and any captcha-type challenge information. That authenticates you in the IB Gateway, and then we can pass orders into IB on your behalf. When you stop the algorithm we log you out of the Gateway.

Check out this video to see what it looks like in the browser. The IB specific stuff starts at about 1:45.

Can I ask why you would implement this way as opposed to doing FIX to ib?

I'd have to go back and check my notes to be sure. I think it was because we thought FIX would talk longer to implement, and would be harder to secure, and we wanted to get live trading to market as fast as we safely could.

I imagine that we will probably implement FIX to IB, and to other brokers, in the long run.

Hi Dan,

I have seen that Quantopian's backtester, Zipline, is open source. Is your API open source as well?

Thanks,
Phillip

Whatever in Zipline is open source. Whatever built additionally on top of Zipline (Web UI, data, transforms, etc.) is not open source.

From Zipline Apache license:
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

So eventually, from my POV, the only argument could be that part of the elements of the 'Live Feed Modules' could be open sourced under Apache (the rest "remain separable"), the rest having been written in a generic way. But why bother considering the interest here is to benefit from their infrastructure .... if one wants their own, get a team and design it.