Back to Posts
Listen to Thread

I tried to implement the strategy can adjust the number of shares held on each trading day based on the recent historic price volatility of the share, with the aim of capping the strategies volatility at some defined level. (courtesy of Tim Meggs) The idea is, #.of shares held across trading day = min(100% , volCap / priceVol) * initialShares, where:
volCap = the required target volatility cap level (user defined)
priceVol = the price volatility (annualized from stddev)
initialShares = the initial # of shares purchased (used as a base)

I then tried it on one of the most volatile stocks, TPX, during the third quarter of 2011 when it's most volatile. The results show a minimized loss.

However, I also tried to implement it during the "good times". This strategy can have a much lower return than the benchmark. It seems that it can only be used during the times of turbulence. Any thoughts on that?

Clone Algorithm
37
Loading...
Backtest from to with initial capital ( data)
Cumulative performance:
Algorithm Benchmark
Custom data:
Week
Month
All
Total Returns
--
Alpha
--
Beta
--
Sharpe
--
Sortino
--
Information Ratio
--
Benchmark Returns
--
Volatility
--
Max Drawdown
--
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Information Ratio 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
This backtest was created using an older version of the backtester. Please re-run this backtest to see results using the latest backtester. Learn more about the recent changes.
There was a runtime error.

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

Log in to reply to this thread.
Not a member? Sign up!