You are correct.
Ironically, I've just finished writing a long twitter thread where one of my comments is about low quality research code
A confession. I often find the implementation of matrices and vectors in pandas/numpy downright confusing. Another confession, I don't write enough tests.
The difference is much clearer with a more pathological example
Code:std = [1, 4, 9] cor = np.array([[1, 0.25, 0.9], [0.25, 1, 0.5],[0.9, 0.5, 1]])
Although it doesn't make much difference to the results of any optimisations or the original risk overlay (as long as standard deviations are in the normal range for financial assets), I have fixed it and named the commit in your honour https://github.com/robcarver17/pysystemtrade/commit/b31ac7e2b4292db0e665d46960820dc402b0c85e
Thanks again. This is the benefit of open sourcing!
GAT
No problem, my pleasure, thanks!
I don't have many unit-tests myself (my stack is C#+sql+matlab with all the real-time trading written in C#, which is at least compilable and strongly\statically-typed, which gives some error-checking, matlab is mostly for reports and graphs).,
In fact I noticed that I only write tests for the parts of the code I don't fully understand
i.e. the more complicated the logic - the more tests I'll write (e.g. for my automatic futures-rolls I have the highest number of tests, like any kind of real-life scenarios I could think of, some probably multiple times, which indicates that I don't fully understand that code and have low confidence in it , so I at least I wanted to check that it does what needs to be done on the actual scenarios).On the other hand, for the code I can read and understand (like all code should be ideally) I don't write tests at all, because they simply add to the code-baggage I need to support, take time, and give me a false sense of security, like "my tests are passing, so all is good" - no, I find it much more important to intrinsically know how your code works (so it should be as small as possible and also simple - i.e. ideal code is no code at all
). Also tests are good if you could get them "for free", but when you factor in the time you have to spend on them, I think it's better to invest it in improving the actual code and architecture (unless you're a huge company with unlimited resources, then sure, just hire 10 more people.. and then your code-base will quadruple in size, no one will know anymore what the system is actually doing i.e. it'll turn into the usual corporate mess ). So no!, big code-base size is a cost, complexity is a cost, time spent on tests is a cost, and therefore all these things should be minimised..I also unit-test complicated math-logic-code (e.g. forecast-functions) where I have concrete expected results to verify against..
In my own risk-overlay code I'm actually doing it slightly differently (hopefully also valid and I'm not doing something idiotic
), I first element-wise-multiply weights with STDs and then risk=sqrt(wStd * corr * transpose(wStd ) ) - which seems to be giving the same result:wstd = w*std
risk=wstd.dot(cor).dot(wstd.transpose()) **0.5 #0.11276790323
Also, instead of using system base-capital I use the total dollar-price of the current positions, and current weights instead of configured ones.
So if currently I only hold 2 GE contracts (1 point=2500$) and 1 NG contract(1 point=10,000$), then my full capital will be 15,000$ and the weights
GE=5,000/15,000=0.33
NG=10,000/15,000=0.67
So these weights will add up to 1.
I then compute the daily portfolio standard deviation (say it's 0.01), multiply it by the current capital-in (15k in this case), which gives me current daily cash risk (15k*0.01=150$), which therefore can be compared to my target daily cash risk (which is say 100k base capital * 0.25 / 16 = $1.562k).
I also use the multiples you proposed originally (2xNormal risk, 2.5xCorrelationBreakdownRisk, 3xVolSpikeRist)., your last 2 numbers in the post are quite higher, not sure if it's because of that bug or something else..
I also compute correlations differently (and here I have no idea if it's "correct or not, or "doesn't really matter"):
for each instrument pair I take 260 daily prices, downsample it to weekly by skipping every 4 points, calculate weekly returns, compute regular Pearson "raw" correlation, and take the average of that result with the 9 previous "raw" correlations.
I then check if the result in not 5x lower or 5x higher of the default correlations you provided in your first book and cap it to these numbers (e.g. if the default correlation is 0.1 and I got 0.6, I'll cap it to 0.5, or if I got 0.01, I'll cap it to 0.02).
So in short I use 1y of weekly returns, averaging 10 last correlations and capping it to be "within 5x" of the default correlations.
All of this probably makes it too slow to react (or ignore) to "extreme recent events when correlations spike".. not sure..
Sorry for too many words
Last edited:
