When building trading models, before taking the model into production because of substantial back testing confirmed by several months of forward testing, the final pre-production validation is done by converting the algorithm to native python, so the two are identical, and then running a closed backtest using something other than Zipline. Plus, it's a bit easier to do diagnostics outside of Zipline.

Recently, a model ready for production went through this final check and I noticed a handful of orders for zero shares were being generated. I thought this was due to something in the native Py version of the code, so I suppressed 0 share orders. Just to be safe, I added the same code to the algo on Quantopian and ran another test. I was shocked to see performance adversely affected. Not significantly over a short time period of 3 months, but enough so that over time, it affects compounded RoR.

I record gross and net exposure because this is a market/dollar neutral strategy designed to handle substantial capacity, with or without leverage (12-20x) with vola still within bounds. When I suppressed 0 share trades with the following code, it caused gross exposure to oscillate in large ranges:

def registerOrder(context, longPos, sym, shares):  
    if sym.symbol in context.orderSet:  
        # log.info('Duplicate order for %s - ignored' % sym.symbol)  
        return False  
    elif shares == 0 and prevent_zero_trades:  
        # log.info('Zero shares trade for %s - ignored' % sym.symbol)  
        return False  
    else:  
        context.orderSet.add(sym.symbol)  
        context.orderList.append(OrderEntry(longPos, sym, shares))  
        return True

def executeOrders(context):  
    for orderObj in context.orderList:  
        order(orderObj.symbol, orderObj.shares)

    context.orderList = []

By changing the 2nd 'return' value to True, it suppresses. False lets the trade go.

Any idea what I'm doing wrong? Are zero trades a bug in Quantopian? What is their purpose?