You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Black Litterman weights should use posterior covariance #762
The relevant equations are Eq(10) and Eq(13) in He, G. and Litterman, R., 2002. The intuition behind Black-Litterman model portfolios. Available at SSRN 334304.
Looked into this before writing any code, because it's genuinely not a clear-cut bug.
bl_cov() (this file, ~line 445) returns Sigma + M, where M is the posterior covariance of the estimate of the mean (the uncertainty introduced by the views themselves — it shrinks toward zero as omega/view confidence tightens). bl_weights() currently reverse-optimizes against Sigma alone.
Whether the final weight/optimization step should use Sigma or Sigma + M is an actual point of disagreement in the Black-Litterman literature, not a settled question with one right answer — some treatments argue M represents estimation risk in the mean and shouldn't be folded into the asset covariance used for portfolio construction (since that conflates parameter uncertainty with return variance and can produce oddly conservative weights as confidence increases), while others include it for exactly the reason raised here. Different well-regarded implementations and surveys of the model land on different sides of this.
Practically, this also isn't a backward-compatible fix either way: test_bl_weights's hardcoded numeric assertions were computed against the current Sigma-only formula, so switching to Sigma + M changes real output numbers for every existing user, not just closes a bug.
Given the genuine ambiguity plus the breaking-change surface, I don't think this is something to just code up unilaterally — happy to implement whichever convention @lballabio (or whoever owns this module) wants, possibly as an opt-in parameter similar to #763/#764 rather than a silent behavior change, if that's useful context for deciding.
Sorry about that — @lballabio tag was a copy-paste mistake on my end from an unrelated PR I had open elsewhere, not this project's maintainer. Correcting: @fkiraly / @robertmartin8, tagging you both since I see you've been merging recently — same question stands whenever you get a chance: should bl_weights() use Sigma or Sigma + M, and if there's no clear answer, would an opt-in parameter (rather than a silent behavior change) be the preferred way to let users pick?
Activity
jrvarma commentedon Sep 21, 2026
The relevant equations are Eq(10) and Eq(13) in He, G. and Litterman, R., 2002. The intuition behind Black-Litterman model portfolios. Available at SSRN 334304.
heykav commentedon Sep 21, 2026
Looked into this before writing any code, because it's genuinely not a clear-cut bug.
bl_cov()(this file, ~line 445) returnsSigma + M, whereMis the posterior covariance of the estimate of the mean (the uncertainty introduced by the views themselves — it shrinks toward zero asomega/view confidence tightens).bl_weights()currently reverse-optimizes againstSigmaalone.Whether the final weight/optimization step should use
SigmaorSigma + Mis an actual point of disagreement in the Black-Litterman literature, not a settled question with one right answer — some treatments argueMrepresents estimation risk in the mean and shouldn't be folded into the asset covariance used for portfolio construction (since that conflates parameter uncertainty with return variance and can produce oddly conservative weights as confidence increases), while others include it for exactly the reason raised here. Different well-regarded implementations and surveys of the model land on different sides of this.Practically, this also isn't a backward-compatible fix either way:
test_bl_weights's hardcoded numeric assertions were computed against the currentSigma-only formula, so switching toSigma + Mchanges real output numbers for every existing user, not just closes a bug.Given the genuine ambiguity plus the breaking-change surface, I don't think this is something to just code up unilaterally — happy to implement whichever convention @lballabio (or whoever owns this module) wants, possibly as an opt-in parameter similar to #763/#764 rather than a silent behavior change, if that's useful context for deciding.
lballabio commentedon Sep 21, 2026
I'm not involved with this project :)
heykav commentedon Sep 22, 2026
Sorry about that — @lballabio tag was a copy-paste mistake on my end from an unrelated PR I had open elsewhere, not this project's maintainer. Correcting: @fkiraly / @robertmartin8, tagging you both since I see you've been merging recently — same question stands whenever you get a chance: should
bl_weights()useSigmaorSigma + M, and if there's no clear answer, would an opt-in parameter (rather than a silent behavior change) be the preferred way to let users pick?