Hello GAT, I'm roadtesting my recently hacked together code to construct Panama curves, but having trouble recreating your results. Taking V2TX as an example I have the following rules defined: v2tx: tenor: m # 1 month behind carry: -1 distance: 2 day_of_month: 16 these rules are used to calculate the Panama adjusted continuous price curve. Comparing the contract date - the index date of my algo and the data in your package: Which results in a price curve: Your curve with MAs and carry rules give a Sharpe ~ -0.1 whilst my version ~ -1 Ouch! From reading your blog I understand that for real trading you are applying discretion in the rolling process - fair enough that my sledge hammer algo. and your data diverge. But how are you determining the roll dates before you started real trading in this instrument? I get similar results for other instruments. Many thanks for all the education.
@djames I fear that you have taken an instrument (V2TX) which is not really suited for Panama stitching. Other instruments, such as metals and grains, are much better suited for Panama stitching.
I'm not sure what you mean by that - could you be more specific? I guess in some ways the point is moot as I'm trying to recreate GATs provided Panama data. In the data he provided is he using an algorithm to determine roll dates for contracts before live trading or is he hand picking them? If it's an algorithm, I wonder what it is doing as it surely is more sophisticated than mine (which isn't hard to do)
Panama stitching is a method which is best suited to stitch two (or more) price lists which have a fixed offset between the two of them. I have an example for corn (ZC): three contracts with different expiry dates. You can stitch the older line to the newer line by "lifting it up". For example: to stitch the blue line to the red line you would add approximately 7 points to the blue line. Then, to stitch the red line to the yellow line you add approximately 10 points to the red line. The second example is for V2TX. Here you see that the price files do not show a more or less stable price gap between the contracts. In fact: the prices are diverging and the gap increases when you get closer to the expiry date. This makes that you would need to do some additional "hand-holding" to stitch these contracts together. Although I prefer to use Panama stitching for most instruments as it is an easy solution, for instruments such as V2TX am I doing a manual way of stitching the prices together. The process is then more based on what I think is right (or visually looks right) for that particular instrument. @globalarbtrader wrote more about stitching on his own blog at https://qoppac.blogspot.my/2015/05/systems-building-futures-rolling.html
Thanks @HobbyTrading, makes sense. I'm still keen to find out from @globalarbtrader how the data for v2tx (and others) included in pysystemtrade was constructed. Perhaps he is using open interest or traded daily volumes as triggers for rolling in this dataset. I'd prefer to code up as much of this logic as possible for the data in backtest . I appreciate that in trading the roll dates become flexible with discretion and passive / active rolling.
I seem to have gotten out of the mire by moving further out on the curve, this gives: (contract date) - date: Panama stitch: I think I can with that discrepancy between GATs data and mine, will see if that's foolhardy or not!
@djames, for what it is worth to you: this is my hand-crafted stitch file for V2TX: It looks not that much different from the one you have created.
Sorry for the delay, been on holiday. Prior to starting collecting live data (~ January 2014) I used a fixed method to determine roll dates; from memory for V2X this would be something like 'trade the second contract roll then trade out the day before it becomes the first contract' (I didn't use volume or any. After that it's down to discretion - but 99% of the time I roll within a week or so of the second contract ageing to become the first. Yes the effect should be smaller as you go out the curve as the roll jumps will be smaller. GAT