Quantopian's community platform is shutting down. Please read this post for more information and download your code.
Back to Community
beta constraint study

Version 1

6 responses

Version 2

Version 3

Version 1:

beta = -0.06
SR_Q = 1.16

MIN_BETA_EXPOSURE = -0.9  
MAX_BETA_EXPOSURE = -0.4  

Version 2:

beta = 0.13
SR_Q = 1.33

MIN_BETA_EXPOSURE = -0.05  
MAX_BETA_EXPOSURE = 0.05  

Version 3:

beta = 0.14
SR_Q = 1.36

    # beta_neutral = opt.FactorExposure(  
    #     loadings=pipeline_data[['beta']],  
    #     min_exposures={'beta':MIN_BETA_EXPOSURE},  
    #     max_exposures={'beta':MAX_BETA_EXPOSURE}  
    #     )  
    # constraints.append(beta_neutral)  

Note:

SR_Q = SR + (risk-free rate)/(volatility)  

And here's my contribution to your study:

Version 4:

beta = 0.13
SR_Q = 1.33

MIN_BETA_EXPOSURE = -0.05  
MAX_BETA_EXPOSURE = 0.05

beta = SimpleBeta(target=sid(8554),regression_length=5)  

Regarding the shorter regression length, I'm wondering if a beta estimate using minute bars would be in order...

@Grant, you can try it. But consider this, the mere fact that a user has the option to configure the window length of the beta already presents a major flaw with regards to contest thresholds which is that beta be between +- 0.3, a fixed range. So when you change the window length of beta you alter the distribution of betas and ranking them will change accordingly so then the relationship between betas and the thresholds given now becomes relative and can be the subject for "gaming", "tweaking" or "overfitting" or whatever you want to call it. Beta calculation should be fixed and standardized to industry best practices, one year daily returns to be consistent with the fixed range thresholds. Therefore, beta calculations should not be exposed to user configuration. I will write about the ramifications of my findings and give my views of the bigger picture in the other thread.