Quantopian's community platform is shutting down. Please read this post for more information and download your code.
Back to Community
Bracketed limit / stop orders, and expando testing

Primitive entry model that uses bracketed orders.

Highlights:
• I think I've plugged all the open order holes. I don't see negative cash or 1.0+ leverage which would indicate doubling up of orders. Not that this can't happen as this is not a true OCA type capability.
• Using standalone methods with schedule_function to drive all processing. I've confirmed that the methods are called in sequence of their registration.
• Trailing stop is self contained. Just schedule the running of that method (and include the two globals).
• Still testing the use of expando properties on the data[stock] objects. Seems to work in bask test mode. Real time is another matter.

Enhancements:
• Use the fundamental retrieval to select a set of better performing securities.
• Swap in realistic entry model.
• Convert to minutely data.

2 responses

Continuing to corral order handling into a reference technique.

In this strategy we see that it take many days to fill the entire order, both for entry and for exit. Change the account bank to see this change. It's useful to understand the slippage under these conditions. The CostBasis reflects this slippage as position is acquired over multiple days. One can comment in the code that checks for either limit order stop touch, cancels both orders and coverts to market for the remaining "Leaves" quantity. This does not change the acquisition behavior though; it takes days to acquire the full position regardless.

Why Quantopian uses the word "amount" when "quantity" is the standard it beyond me.
"What's the amount on the bill?" "$17.52"
"What's the quantity on the bill?" "What?" "What's the quantity on the AAPL order?" "100" "What's the amount on the AAPL order?" "What?"

Also used is an "UpdateState" method which tries to simply the usage of position state (work in progress).
Additionally, the trailing stop code in ExecuteExits now takes into account long or short positions.