The zipline backtester isn't well set up to track 'lots' or sub-portfolios. Certainly saving the order objects isn't a good practice. As noted, the amounts and prices won't be adjusted for any splits or dividends.

One solution may be to track the 'weights' of each holding within each sub-portfolio. Maybe a dataframe with securities as the index and columns representing the percentage of the total holdings associated with each portfolio. The sum of the columns for a given row should always equal 1 (or maybe zero if no positions are held). Whenever a new position is opened, find the row associated with the security and update all the column values to the new percentages. Use the dollar value of the position and not the shares.

When one wants to close out a sub-portfolio, simply go to the associated column. Loop through all the securities with non-zero weights and close out the associated percentage of total holdings for each security. This can actually be done in one step by creating a series from the column and then using order_optimal_portfolio with a target weight of 1-my_series.

There is another "oh by the way". The above method won't account for any added shares for spinoffs or for dividends. Consider the case where a company spins off a subsidiary. For example SHLD spun off Lands End in 2014 (https://www.forbes.com/sites/samanthasharf/2014/04/07/sears-completes-lands-end-spinoff/#3fcd2eae1efc). The backtester will magically add new shares of Lands End to the total portfolio to reflect this spin off (similar to what a real broker would do). It will be difficult to go back and equate those new shares with the shares of SHLD. There's no good way to proportion those new shares between the portfolios. A similar issue happens with dividends. Dividends will be deposited into the total portfolio and will be difficult to proportion to the proper sub-portfolio.

Hope that helps a bit.

Hi Dan,

thanks for your reply.

I don't think that will work for me... the percentage weight that each security represents in a subportfolio will change as the price evolves. Probably best for me is to use backadjusted data, so I will need to step outside quantopian for this. Backadjusted data is readily available and already adjusted for the effects of splits, dividends etc for exactly this purpose.

Just to be clear though, my problem is not related to subportfolios... that is just how I came across the problem. Subportfolios work fine within the quantopian and python class structure.

The problem is that the initial order quantity is not updated after a stock split, but the portfolio position size is. That means that if I buy 1000 XYZ today, my portfolio will show a position size of 1000. If there is a 2:1 stock split tomorrow, my order will still show 1000, but the portfolio will show 500. The current quantopian practice does not keep the two things in sync.

This means that it is very risky to use the amount returned by the get_order function... the amount you get back represents the state at which the order was placed, not the current state. I understand why you have done that, but it essentially means that it is not possible to manually control your own orders in an algorithm... (the functions are provided to allow you to do that, but if a stock split occurs, then the results are wrong).

I think it would be wise to put a note to this effect into the documentation... I can't imagine any other use case which involves the get_order function which isn't affected by this

Cheers,
Bruce

You are correct that order info isn't updated for corporate actions. This is actually one of the reasons why all orders are 'Good-Till-Day' (GTD). If an order were allowed to span multiple days then it would need to be adjusted for corporate actions such as splits. As a rule of thumb, just like prices and volumes, don't save order values from day to day.

What I had suggested was not to save the percentage weight of a stock in a sub-portfolio. I'd suggest saving the percentage of each stock across the sub-portfolios. As an example, consider the case of three sub-portfolios and a single stock IBM, and a 'context.weights' dataframe. Let's also assume that all orders fill complete. Before, any positions are opened 'context.weights' will be empty.

Now, one orders 100 shares of IBM for portfolio1. The 'context.weights' dataframe would look like this

stock    port1    port2    port3  
IBM       1.0      0.0      0.0  

What this means is 100% of the shares of IBM are allocated to port1.

Now, on the following day, one orders 100 shares of IBM for port2. The 'context.weights' dataframe should be updated to look like this

stock    port1    port2    port3  
IBM       0.5      0.5      0.0  

There are now 200 shares total across all portfolios with 50% allocated to port1 and 50% port2.

Now, on the following days, one sells 50 shares of IBM from port1 and buys 50 shares for port 2. The 'context.weights' dataframe should be updated to look like this

stock    port1    port2    port3  
IBM       0.25     0.5      0.25 

This will track how the total shares of each security are allocated across each portfolio. It's not the percentage of weight within the portfolio. Before updating the dataframe, simply check the total shares held using 'context.portfolio.positions'. Use that share quantity to base the updated percentages on. The share quantity in 'context.portfolio.positions' is updated before trading each day to reflect any corporate actions. That will ensure the percentages are always correct. Note too, that the percentages for each row should always total 1.0.

This doesn't solve all the issues as mentioned above, but will track the current percent of shares to be allocated to each portfolio for each security.

Hi Dan,
thanks for this excellent reply.
Unfortunately I don't think it will work in my specific case. I need to keep each portfolio's $ separate. Each is initially seeded with the same amount of money, but the portfolio values will diverge over time as the simulation unfolds.
As an example of the problem this would cause, imagine in your example when I come to sell the percentage held by IBM in any given portfolio. A specific portfolio may hold 25% of the IBM stocks, but the actual return for the portfolio will depend on which 25% are sold... ie there will be repeated buys at different dates across each portfolio. If I sell the first 25% bought, the $ result would be very different to selling the last 25% bought.
Cheers,
Bruce