It may be because your stop loss "if" statements are nested within your coin flip "if" statement. If coin>.5 AND you don't own it in your portfolio, you order 20000 of KO. But after that, the stop loss would never execute because even if coin>.5, you already have it in your portfolio, so the condition can never be True a second time.

Also, your "if coin<=.5" is nested within the "if coin>.5" block). Maybe try moving the "if coin<=.5" block to the left 1 indent and moving both your stop loss blocks outside and rework the conditions?

Joe,

Yep--thanks for the help. I'll post again here as soon as I've edited.

I'm having problems with the order object fill and position value calculation which is used to process the stop order price execution. I've inspected the 1 min bar transaction results, and could not get the position stop to calculate the proper stop price, so I removed the stop price functionality from my algorithm. I perform a bar by bar inspection of maximum or minimum price to determine if the projected stop price has been triggered. This is a much 'cruder' process, but at least gets close to the desired transaction behavior versus in come cases almost doubling the position loss when a stop price is 'missed'. To inspect this behavior, please read the portfolio.pnl execution problem posts and run my portfolio.pnl example code to clarify the problems with the order object transaction process...

Hey Mark,

I read through your post and it really does seem like there's a bug with what Quantopian has implemented. I updated everything I'm using to try to avoid using the position fill value (although that shouldn't change anything) and also updated it to print out the daily price. I'm still having stop losses that don't execute when they should, and that execute when they shouldn't. Besides I can't get an accurate fill price for anything.

Before I go your route I'm going to wait and see what the Quantopian team has to say--I'm not in any hurry but I've debugged this as much as I can see and it all should work but it doesn't. My code now prints out a log of the daily price, the position I'm taking (whenever I take one) the price I am long or short at, and whenever the stop loss raises or lowers that also prints out--all to the Log. Matching this with the transaction details and the price chart shows that something is wrong. Good luck! I hope this gets sorted.

Try this for your coin flip code, it has track_orders turned on. Incidentally I made some changes for my own ability to read the code, run this and after you fix whatever it was that I might have broken (random present and I didn't have the patience to debug or think it thru) pretty sure you'll find track_orders useful for visibility into the stop losses.

Jacob,

Sorry I've taken so long to get back to you. Let's try taking this from step one. I narrowed down your code all the way down to its most basic elements where you execute 1 long and 1 stop order. Here, your stop-loss does execute.

I think perhaps if I gave an explanation on how the Stop order gets triggered we may be able to dig down into the deeper issue. A stop order will get triggered when the closing price of a bar meets the stop order conditions. I think this may explains why Mark's maximum and minimum calculations weren't reflected in the stop orders. The code for how a stop order gets triggered is here in zipline (https://github.com/quantopian/zipline/blob/master/zipline/finance/slippage.py).

So to get back onto your main point. Jacob, when EXACTLY do you see your stop-orders not executing? It'll be helpful to get it from your point of view to understand which section of the code is bugging you the most.

Thanks
Seong

Seong,

It appears Zipline's stop loss trigger methodologies and practices for filling a market order at the next bar closing price are at odds with normal professional trading platform practices. Have you compared these practices with those incorporated within the IB platform? Do the 'IB order / stop loss objects' provided within Quantopian behave the same as within the IB platform, or are they simply Zipline order objects passing a trading signal to a related IB account? The Quantopian order object doesn't acknowledge fills or display a fill price which would be helpful to debug the appropriate stop loss exit.

Thanks
Mark

Gary,

Thanks for trackorders--and for showing how to clean up the code by assigning everything abbreviations at the smart--super clever. I'm using your track orders and summary methods now, but still running in to the same bugs.

Seong,

You got back to me super fast! Thank you. If you reference the backtest attached to this post, I will explain day by day the behavior I see that is different than expected.

Everything that I expect to happen occurs until February 24th, 2010 . On February 24th, the algorithm goes short 199 shares of SPY at 110.82. This should also put a stop at 110.82*1.005=111.37.

The price of SPY definitely goes through 110.82 between February 24th and May 20th, 2010, but no other trades execute during that time.

Finally, the last transaction made by my algorithm is on September 1st 2010, where the algorithm goes short 205 shares at 109.46. That should put the stop at 1.005*109.46=110.01. However, another trade is never executed for the next 4 and a half years...

Thanks for your help both of you.

Hi Jacob,

So I guess I'm a little confused with what's going on. It looks like, for the most part, that your orders are executing AS expected. Because on February 24th, your orders for 199 shares are actually filled which means that there is no longer a stop order waiting to be executed. And if you log 'get_open_orders()' you'll see that it stops on September 1, 2010 meaning that there are no longer any orders that are actually waiting to be filled which also means that these conditions:

if (context.longnow==0) and (data[context.security].price*1.005 < context.stopprice) :

Aren't actually being triggered. Does this make sense to you? If so, let's talk about how we can change this to get the behavior you want

Seong