Yeah, the return is pretty outrageous. I cloned your algo and took a look. The key is that your algorithm started with $10,000 and then leveraged itself like crazy - by March you had a million dollars of Apple stock, which you obtained by borrowing $700,000. A neat trick, if you can get someone to loan that to you!

What you need to do is edit the code and reduce the "max_notional" you have there. Don't let you portfolio long position get to $1,000,000. And, since you are buying Apple, don't buy 100 shares at a time, buy 5 or 10 - you can't afford 100 shares when you have only $10,000. That would bring your return back down to reality.

As for things like latency - that's not going to be a factor in this case. The backtester is event driven. You place the order in one minute. The order is filled in the next minute, according to the prices in the next minute. That's a pretty decent match for the real world. You don't get the prices you see this instant; you get the price that is true when the order actually executes.

Actually, there's another post this week you should look at: https://www.quantopian.com/posts/theory-of-anti-gravity-with-overdraft-control

That has a lot of the preventive code you need to avoid unrealistic borrowing scenarios.

Hi Dan,

Well...a minor correction is that a placed order doesn't get filled until the next tic of the security. In the case of an order submitted during the last trading minute of the day, it won't get fulfilled until the first tic of the next trading day. And for thinly traded securities, it could be more than a minute before a submitted order gets filled, even in the middle of the day. In the case of thin trading, there is latency, as there should be, to emulate the historical market conditions. For Apple, however, I'm guessing that there is a trade every market minute in your database.

Right?

Grant

Grant, you're right, but I think the original questioner was concerned that the backtester might have very low latency and fail to represent real-life, which has longer latency. What I was trying to say is that the backtester deliberately waits one cycle, and that (hopefully) makes the backtester have "the same" latency as real-life. So, as in the case of the thinly traded stocks, the stock might not trade every minute, but the backtester is still modeling things reasonably well.

It's worth noting that even Apple has gaps.

Also https://www.quantopian.com/posts/my-overdraft where I outline some measures you can add to prevent your algorithm from assuming an unrealistic relationship with your banker.

Thanks Dan,

It's a subtle but important point that the backtester is event-driven off of security tics, not clock tics.

Regarding latency, this discussion raises a question in my mind. It seems that the real-world delay between order submission and order fulfillment should be considered when backtesting. Is it realistic that orders would be filled so quickly and consistently? Or should we be thinking about a function like:

order_with_latency(sid,amount,latency)  

Latency would be specified in tics (days or minutes), with order_with_latency(sid,amount,0) equivalent to order(sid,amount). Order fulfillment would be delayed N tics (N > 0) for order_with_latency(sid,amount,N).

An extension would be:

order_with_latency(sid,amount,mean_latency,jitter)  

The jitter parameter would add noise to mean_latency, so that variability in the latency could be captured in the backtest.

I'll do a separate post to see what members think.

Cheers,

Grant

Dan,

See the log output of the attached backtest...yep, the suspended trading of AAPL is in the Quantopian data...nice example!

However, there is no indicator in the Quantopian database that the market was closed for AAPL during the time period. Something to consider...

Grant

I'm starting to enhance the order system of zipline to differentiate order types (market, limit, stop, stop_limit, etc.)
and how they get filled and canceled. This is an interesting aspect, seems it is similar to how slippage is dealt with.
Perhaps a LatencySlippage object so that the parameters can be passed in the initialization phase

Tony,

Sounds good. Note that I started a separate discussion, if you want to post ideas there (https://www.quantopian.com/posts/order-fulfillment-latency).

Grant