And just to clear it up a little, it's not dependent on a particular asset. e.g. next time you run this, it could happen with a different sid. I don't think it's a symbol vs. sid bug

Interesting scenario! You presented a very elegant algo to show the problem.

This looks related to a recently discovered bug and we're working on a fix. It's related to placing an order inside a loop that is iterating over positions. I'll let you know once it's patched and thanks again for the well written algo.

That was a great example, thank you. Definitely made my head pop when I saw it - that shouldn't happen!

The bug was fixed and shipped last night, so you shouldn't be able to reproduce it now. The underlying problem was pretty impressive. When a stock was held and then closed, when it was closed the positions object was being left with a vestigial object. When your code later iterated over the position, it could end up re-ordering the positions object, even mid-loop. That meant that a single stock could be processed first in the loop, then the object get re-ordered, and then the stock would be last and the re-processed. Very confusing behavior for sure.

I'm sorry for the frustration I'm sure this caused.

Dan, Alisa, thank you both for your quick response. I retested the algo and while the problem appears resolved for daily, it still seems to show up in minutely. I attach the even more simplified algo backtest.

This is the backtest behaving as designed, though it might not be intuitive. Let me explain what's happening.

The algorithm is filling orders across multiple bars according to the default slippage model, which will trade up to 25% of the stock's volume for that bar. If you're trying to place an order that accounts for more than 25% of the stock's transacted volume, the remaining shares will get filled in the following bar. To fill your entire order in each bar, you can force the slippage to 0.

When you account for slippage, here is your algo logic:

• Bar 1: Portfolio value is 0, submit an order
  
• Bar 2: Portfolio value is 0, fill the order
  
• Bar 3: Portfolio value > 0, sell the stock
  
• Bar 4: Portfolio value > 0, sell the stock again (note: the order wasn't completely sold in the previous bar so now you're shorting the stock)

When the sell orders from bars 3 and 4 are filled, your portfolio value is < 0 and the algorithm stops placing additional orders.

To fix this logic, try placing new orders only if there are no open orders. Take a look at the attached algo, I think this is working as expected.

My bad. Thanks!

EDIT: Don't mind this post, get_open_orders() is a dictionary of sid's

@Alisa

I am curious, in the above, why did you not just use:

    for oo in get_open_orders():  
        message = 'Open order for {amount} shares in {stock}'  
        message = message.format(amount=oo.amount, stock=oo.sid)  
        has_orders = True  

instead of

    for stk in data:  
        orders = get_open_orders(stk)  
        if orders:  
            for oo in orders:  
                message = 'Open order for {amount} shares in {stock}'  
                message = message.format(amount=oo.amount, stock=stk)  
            has_orders = True  

I'm rather new, and trying to acquire best practices

I am having the same issue that Sekuri originally had. My algo sells twice what it previously purchased. However, I am not having this issue with order_target_percent(); I am having the issue with order_target(). Is it possible that the 'purchasing multiple times when within loop' issue still exists with order_target() because I've tried everything. I've controlled orders to only execute if no current orders are open and that hasn't worked. I've also limited execution of the buy/sell orders to occur every half hour and made each order action place a log entry. I've simply found that log entries indicate a single sale order of context.portfolio.positions[stock].amount and Transaction Details in the backtest indicates an order value double that of context.portfolio.positions[stock].amount.

I just modified my algo to work with order_target_percent() and I am no longer having issues. So the problem must be exclusive to order method order_target()! Please help Quantopian Staff