Great work Taibo! Out of interest, how did the algorithm's volatility stack up versus that of the underlying stock? Given the intent of the strategy is to limit/cap the algorithm's volatility I'd hope the realised vol of the strategy was indeed less during periods when the stock volatility was > volCap.

Also, another thing worth thinking about is the volatility metric used. For equities, one of the best predictors of t+1 volatility is the exponentially-weighted realised volatility (60-day window tends to correlate quite well) as opposed to the flat-weighting currently used. The EWA measure tends to pick-up changes in regime slightly quicker. Adding EWA as an extension of the current Zipline volatility calculation is something that would be really useful. Perhaps one of the Python-savvy community members might give it a go?

Oh thanks Tim for the comments! I assume you want to modify the stddev() method to achieve EWA, right? Probably Quantopian could add in that transform? :)
As for the volatility, they way I want to check it is to log the actual annualized volatility after submitting those orders and compare them before that. Do you have any thoughts on it?

@Tim actually I tried to log annualized volatility info but failed to check whether stddev is limited because this algo in fact dynamically changes the number of shares at hand and can't really be compared... em maybe we should just compare this algo with the simple buy-and-hold algo as you suggested? :D

@Tim actually I tried to log annualized volatility info but failed to check whether stddev is limited because this algo in fact dynamically changes the number of shares at hand and can't really be compared... em maybe we should just compare this algo with the simple buy-and-hold algo as you suggested? :D