Thanks Fawce,

A few questions:

1. I don't see how your code knows if a stock in your lists is available for trading on Quantopian/IB on a given date, when the rebalance function is run. When the pipeline is run, does it filter out all stocks that are inactive within the 10-day window, by looking at their start and end dates in the database? I'd assume that any stock that ends up in your long and short lists would need to be active for the full window, correct?
   
2. Is there any way to use pipeline to deal with stocks that have end dates within the backtest timeframe? Say I wanted to avoid stocks that will expire within 20 days? Could I filter those stocks out using pipeline, or would I need to add a screen within the algo?
   
3. I suspect that most (all?) expirations are scheduled events. Stocks aren't just de-listed at the drop of a hat. Is there a path to make this information available in Quantopian? One can arbitrarily try to avoid holding stocks about to expire with something like:
   

for stock in context.stocks:  
        if stock.security_end_date < get_datetime() + datetime.timedelta(days=20):  # de-listed ?  
            context.stocks.remove(stock)  

However, it could result in bias. It also means that the backtest needs to end 20 days before the current date. Under live trading, it seems like there is no way to avoid scheduled de-listings.

Grant

Hi Grant,

Thanks for the questions:

1. My code is ignorant of the start/end of stocks. Knowing the date a stock stops trading would be a form of look ahead bias, so pipeline handles the arrival/departure of stocks internally by masking the assets to exclude defunct stocks. Assets will be masked out the day after their end date. That means that if you have a 10 day look back, an algo-time currently expired stock will not show up in the history window, even if the stock was active in that historical period.
   
2. We don't have data for delistings, but the exchanges do publish pending delistings. Nyse's is here. Besides delisting, stocks also expire because of mergers, and we do have acquisition and mergers from EventVestor.
   
3. NYSE issues a notice 10 days in advance of delisting. There are many criteria, but the most common reason is falling below market cap or price requirements. You could approximate delisting criteria with pipeline, and just screen out companies that are close to the delisting requirements.

happy coding,
fawce

Thanks Fawce,

If I'm looking back 10 days, would pipeline include stocks that have their start dates within the 10-day window (assuming that their end dates are outside the window)? Or does it require the window to be within the start and end dates? It seems like one would want all stocks within the window to have started trading and not ended trading. Otherwise, for example, you could end up with some stocks that only have a few trades, while others will have 10.

Knowing the date a stock stops trading would be a form of look ahead bias.

I agree. However, the problem, of course, is that in backtesting, one can end up with stocks that can't be sold, because the backtester doesn't support transactions beyond the end date. For live trading, it must be the same--nothing can be done via the Quantopian trading platform. IB would need to perform the transactions or a user could do them manually. So, my thinking is that there should be a way with this new pipeline thingy to filter out stocks that are gonna cause headaches in backtesting/live trading.

Could anyone knows, how to get value of dollar_volume in rebalance function?

 This rebalancing is called according to our schedule_function settings.  
def rebalance(context,data):  
    long_weight = context.long_leverage / float(len(context.long_list))  
    short_weight = context.short_leverage / float(len(context.short_list))  

I want to sum 100 stocks's weight(all stocks' dollar_volume )
formula:
(one stock's dollar_volume)/(sum all stocks' dollar_volume)

Not use the equal weight.

Thank you very much.