timeseries.cone_rolling needs refactoring

[twiecki]

@justinlent and I just looked at the code in cone_rolling. While functional, as we're relying on that code more and more it should be more robust. There seems to be an issue with <= logics, the warmup-period is obsolete, it's not tested etc. Probably a clean rewrite is the best path forward.

[twiecki]

@acampbell22 Is that something you could help with? I think the complete code should be rewritten from first principles.

[twiecki]

Moreover, a nice addition would be if it were possible to output the cone in a dataframe so that we can add automatic checks if a cone was breached.

[a-campbell]

Started looking at this last night. Will get going on a refactor soon.

[twiecki]

👍

[a-campbell]

Do we want to continue to support the extend_fit_trend=False (refit linear cone with ever additional day of data) option? It adds a lot of complexity and isn't used in the full tear sheet.

[twiecki]

Agreed, lets drop that.

[a-campbell]

Is it right to use the slope of the line fit to the backtest cumulative returns as the slope of the midline of the future cone projection? If an algo returns 10 bps per day, its equity curve will have a much higher linear fit slope over a 13 year backtest than it will over a 1 year backtest (compounding).

Would it be more correct to project the backtest CAGR forward?

I am trying to make the "cone bounds" function as generalizable as possible. Should be applicable to any OOS starting portfolio value.

[justinlent]

Hey Andrew, yes I agree simply applying the CAGR from the backtest as the OOS trend projection is a better, generalized implementation. I actually used that is a way to check the math of the regression approach if I recall since they should be equivalent when the regression is done with the intercept term (which I think is how it was implemented originally). 

Sent from iPhone

_____________________________

From: Andrew Campbell notifications@github.com
Sent: Monday, November 23, 2015 4:50 PM
Subject: Re: [pyfolio] timeseries.cone_rolling needs refactoring (#178)
To: quantopian/pyfolio pyfolio@noreply.github.com
Cc: Justin Lent justinlent@gmail.com

Is it right to use the slope of the line fit to the backtest cumulative returns as the slope of the midline of the future cone projection? If an algo returns 10 bps per day, its equity curve will have a much higher linear fit slope over a 13 year backtest than it will over a 1 year backtest (compounding).

Would it be more correct to project the backtest CAGR forward?

I am trying to make the "cone bounds" function as generalizable as possible. Should be applicable to any OOS starting portfolio value.

—
Reply to this email directly or view it on GitHub.

[justinlent]

@a-campbell ,
After sleeping on it, I think we'll want to try out both applications (the mean daily return, and the CAGR approach) to see what feels the most correct. I'm a bit torn now that I think about it. Since the cone is calculated everyday for application of risk monitoring in more or less real-time I feel like we should be using the simple mean returns.

As I see it, we have 2 approaches up for debate for drawing the slope of the line that bisects the cone (the 'mean' of the cone) which are dependent on choosing how to compute the OOS daily return projection. So should this daily return be computed as:

a) mean(backtest_daily_returns)
b) (1 + backtest_CAGR)^(1/252) - 1

@twiecki What's your vote? :)

[twiecki]

@a-campbell Just chatted with @justinlent internally and the compounding issue makes this all a bit weird. One thought is to instead use the Bayesian cone which does not have that issue rather than retrofit and refactor the existing one but other options also appear feasible.

Specifically, we could first compare these cones:

1. current linear cone
2. simulation from a normal distribution fit and monte-carlo simulation
3. bayesian version of normal distribution fit and monte-carlo simulation
4. bayesian version of T distribution fit and monte-carlo simulation

As we have data we can validate this more thoroughly which we should do to begin with if the cone were to become a more important measure. The key insight I suppose is that we should do that validation before putting in effort to rewrite the current method that might become obsolete.

Thoughts @a-campbell? CC @Jstauth