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?