By attributions I mean: the contribution of each market to this month's return. To decompose the monthly return into its individual contributors... Value I meant some form of measurement of value such as e.g., P/E with equities. But it sounds like you've not looked at this, which is fine. Relative value sounds interesting...
easy: system.accounts.portfolio().to_frame().monthly Value: oh sure, yes I looked at aggregated PE for equity indices and other metrics like yields, quality etc. It sort of works okay but it's quite highly correlated with carry. I also looked at using bond yields, but again they're very similar to carry. In other futures the notion of value is rather abstract - what is value in Corn? The main problem with these strategies is they are big consumers of data for not very much extra return. GAT
Hi GAT, I noticed in your instrumentconfig.csv file your Github account that the contract multiplier for KOSPI is off vs Interactive Brokers contract specifications, by an order of x10 (you can click the links). Is this intentional due to some sort of indirect currency multiplier, a mistake or is there something I am missing? Thanks! AG
I note that the larger contract has also a different multiplier (250,000), or have I gone wrong somewhere?
According to the webpage of the Korean Stock Exchange: mini KOSPI200: "Contract Size Mini KOSPI 200 futures price times KRW 50,000" http://global.krx.co.kr/contents/GLB/02/0201/0201040204/GLB0201040204.jsp KOSPI200: "Contract Size KOSPI 200 Futures price times KRW 250,000" http://global.krx.co.kr/contents/GLB/02/0201/0201040201/GLB0201040201.jsp
You're correct. For the contract I trade (large size) it should be 250K so out by a factor of two. For interest I verified this by dividing the current contract value on IB page (KRW 76,916,748.05) by the price (KRW 307.666992). Github should now reflect this. Good spot. An excellent example of the benefits of open sourcing your code (many eyes make all bugs shallow, and all that). GAT
It's a pain whenever the exchange changes the contract specs. Ideally IB should notify its clients trading this. Pysystemtrade is great and it's extremely generous that you share this with the world. I learnt a great deal, thank you for that. Out of curiosity: on what aspects would think it falls short of what professional hedge funds are running? Also: being a few years into it, are there design choices you regret? Thanks for your insights and generosity again.
It might not be clear but psystemtrade is 'version 2' - Version 1 of my code I wrote a few years ago, and I'm actually still running since pysystemtrade isn't yet a full featured end to end trading system. Most of the design choices I regretted in version 1 I've subsequently fixed (or will fix going forwards as I develop it further). I've given a lot of thought as to how to put together the various components of a backtest in a natural way, although to be fair I've seen systems that have 'magic glue' that works better (i.e. if you create a new method of position sizing you don't have to override the class methods of an existing object to make it work); however I think the internals of these systems are more difficult to understand and I prefer the transparency. In terms of how it compares to a professional system, well firstly it's incomplete as I've already said. However in its complete form it will fall short in two main areas - tests and robustness (the main difference between amateur and professional software!), and speed (it's all python, whereas a professional system would probably have critical parts rewritten in C++). GAT