Altan

Welcome, and yes, that algorithm in the tutorial is pretty simplistic and misleading. As you found out it doesn't work as it would seem on the surface.

First off, the handle_data function is automatically called every minute. Ultimately you may want to put your trading logic there, but for starters it's easiest to put it into a scheduled function. Attached is a sample algorithm.

You noted three things that are happening in your algorithm. 1) slow 2) a lot of buying and selling 3) huge losses. As far as why, here's my guess...

1) its slow because the handle_data function is called every minute and you are placing orders every minute of every day. Normally, there would be some logic like "if price is less than x then place order" so your orders would be much less frequent.

2) its buying and selling a lot because the order_target_percent function doesn't check for outstanding orders. It only looks at cash and equities currently in the portfolio. If you start with $1M cash then the very first minute of the algorithm an order for $1M worth of shares is placed. The very next minute, only some of that order would be filled based upon the slippage model. Lets assume $100k. So, the second minute, you still have $900k in cash in your portfolio so the algorithm places an order for $900k worth of shares. As the orders are filled your portfolio now has way too many shares so the order_target_percent now starts selling shares. That cycle keeps repeating. Note that all outstanding full and partial orders are always cancelled at the end of each day so that makes for a sort of "reset".

3) it has huge losses partly because of commissions. It's often helpful while testing an algorithm to set the commissions to zero using the set_commission function.

By using a scheduled function to trade once a day all the above issues are eliminated (potentially the same could happen however if it wasn't for all outstanding orders being canceled at end of day).

Hope that helps. Good luck.

Thanks. The minute resolution would certainly explain the speed but how a backtest can generate beyond -100% is quite enigmatic. The logic must be acquiring and disposing of quite a bit over and above the value of the portfolio since buying and selling a fraction of the portfolio would not result in a loss greater than the portfolio itself - (unless transaction costs have a minimal value rather than a % of portfolio value but even then it should stop at -100% - final tr costs). I would have expected that once 100% of the portfolio is allocated to apple the portfolio should track apple's performance statically. Is there a way to write the daily portfolio value and buy and sell orders to a csv file to audit the results?

Altan,

Maybe attach a backtest highlighting your concerns. Attached here is a minute version of simply buying 100% AAPL and it seems to work as expected?

Look at the "transaction details" tab in the left menu area of the full backtest and you can see exactly the minute by minute trades. This often helps in troubleshooting. Notice in this backtest the order_by_percent does overshoot so after a few minutes it is actually selling shares (which it over bought previously). Notice too that the constant compounding of orders does NOT happen probably because there is so much volume in AAPL and your order gets filled in a few minutes.

Thanks. The algo doesn't stop buying after it reaches the portfolio amount. It also ends up net short and static short Apple (adjusted for dividends and splits presumably) until the end. I read your solution of reducing the trade frequency with the schedule function to end of day, but this is sidestepping the problem. Even on a minute basis if target portfolio is 100% the algo should buy up until the % amount (save for the fraction of Apple share that can't be bought). On default behaviour, a model like this should be able to get all the units it needs by the end of the day (perhaps with some cost adjustment to the closing price). Continuous compounding must still work with one minute resolution.

Hi Altan,

The algorithm is creating new orders every minute, even if there are current open orders being placed..

Think about it like this:

Let's say Stock J's share price is $1000.
With $1m starting capital, the following will happen.

Start of Minute 1:  
# Order 100% of portfolio value  
order_target_percent(symbol("J"),1)  

50 seconds after the start of minute 1:  
There is an open order for 1000 shares of Stock J,  

Start of Minute 2:  
500 shares of Stock J have been filled.  
# This means that there is still an open order for 1000 shares of Stock J, but it is partially filled.  
order_target_percent(symbol("J"), 1)

# Your portfolio value is still $1m, so this targets to $1m based on the number of shares in the portfolio.  
# 500 shares of Stock J are ordered  

50 seconds after the start of Minute 2:  
The previous order from Minute 1 has been completely filled. (1000/1000)  
There is an open order for 500 shares of Stock J  

Start of Minute 3:  
400 Shares of the order were filled. (400/500)  
# Portfolio value at $~1.4m  
order_target_percent(symbol("J"), 1)  
# Order placed to make ~$1.4m to $1m  
(-400 shares)

50 seconds after minute 3:  
Order for 500 shares filled.  
Open order for -400 shares.  

This is all assuming that the price doesn't change from minute to minute, in which case it would rarely converge to a correct price.

If you were to change handle_data to return when there are open orders, you'll get the correct behavior.

def handle_data(context, data):  
        if get_open_orders():  
            return  
        order_target_percent(symbol("J"), 1)  

This should converge to your target price.

Best,
Lotanna Ezenwa

Controlling for open orders does indeed stop the issue. Thanks.