Measuring most active contract months

Discussions about the testing and simulation of mechanical trading systems using historical data and other methods. Trading Blox Customers should post Trading Blox specific questions in the Customer Support forum.
Post Reply
cbrenner
Roundtable Fellow
Roundtable Fellow
Posts: 50
Joined: Wed Aug 27, 2003 4:09 pm
Location: Washington

Measuring most active contract months

Post by cbrenner » Wed Jul 09, 2008 9:58 pm

I thought it would be best to query members of the forum first before I head off on another time consuming endeavor.

I use fix roll days as opposed to using OI and/or Volume. I don't want to roll into a new contract every month for futures (e.g., CL, RB, PN, etc.) which have monthly contracts (FGHJKMNQUVXZ) if the nearest month has less activity/liquidity than, for example, the 2nd or 3rd, etc. nearest month. Of course, this would also hold true for futures that have less frequent trading months. Clearly, avoiding increased slippage and excessive commissions are key concerns here.

Ultimately, I would like to deselect the contract months that are least active so these are ignored in CSI's UA when building the data series. So, my questions are:

1) Has anyone already done any historical testing/analysis that they would be willing to share which presents the most active and least active months for all futures (or a subset thereof)?
2) If no to #1 above, does anyone know if such data is publicly available somewhere?
3) Does anyone see any problem with deselecting the historically least active/liquid months.

I guess another way to do this is in real-time if CSI’s UA had the capability to combine roll trigger’s in a way where you could do something like:

IF (X days from start of Month Prior to Delivery Month (MPDM)) THEN ROLL TO (Future Month with highest OI and Volume)

Unfortunately, unless I’m missing something, I don’t think that such a multi-dimensional roll trigger exists (as least in CSI’s UA).

Assuming that none of the above are available and prior to fully engaging my brain on this, would anyone have any suggestions as how best to create such a reference table (using TB, Excel, etc.)?

Thanks,
Craig

sluggo
Roundtable Knight
Roundtable Knight
Posts: 2986
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo » Wed Jul 09, 2008 10:47 pm

User "Chelonia" has studied fixed date rollovers, and presented his findings here: viewtopic.php?p=24283&highlight=workable#24283

Users "Hiramhon" and "Bondtrader" suggested and implemented and uploaded to this website a cute idea, here: viewtopic.php?p=6203&highlight=cleven%2A#6203

If you require more rollover options, possibilities, choices, triggers, filter conditions, and exclusions than CSI Unfair Advantage offers, you may want to explore the idea of hiring a programmer to write a custom "Continuous Contract Builder" application just for you. Reputedly you can hire Computer Science Ph.D's in eastern Europe for US $20/hour on coding jobshop websites. If the project requires 40 billable hours (which is a LOT!) that is "only" $800, to get it done exactly your way according to your specifications. Less than a one-day stopout on a single contract of Natural Gas.
Last edited by sluggo on Wed Jul 09, 2008 11:41 pm, edited 1 time in total.

cbrenner
Roundtable Fellow
Roundtable Fellow
Posts: 50
Joined: Wed Aug 27, 2003 4:09 pm
Location: Washington

Post by cbrenner » Wed Jul 09, 2008 11:38 pm

sluggo wrote:Chelonia has studied fixed date rollovers, and presented his findings here: viewtopic.php?p=24283&highlight=workable#24283
Yep, I've seen this previously. Certainly helpful in establishing the roll dates but not the underlying question of "Which contract months are historically least active and have the lowest liquidity (and subsequently should not be traded).
sluggo wrote:If you require more rollover options, possibilities, choices, triggers, filter conditions, and exclusions than CSI Unfair Advantage offers, you may want to explore the idea of hiring a programmer to write a custom "Continuous Contract Builder" application just for you. Reputedly you can hire Computer Science Ph.D's in eastern Europe for US $20/hour on coding jobshop websites. If the project requires 40 billable hours (which is a LOT!) that is "only" $800, to get it done exactly your way according to your specifications. Less than a one-day stopout on a single contract of Natural Gas.
Hmm, having been in the software application business, I think this approach (although custom for my needs) would overly complicate things (i.e., providing product requirements, reference specifications, development time, bug testing/fixes, etc.)

I think it might be more productive to see if CSI can add functionality (as I described in my original message) into UA or maybe create an API to allow for some custom development. It might take a bit longer but they already have 95% of what I need built into UA.

In the meantime, it appears that I will need to find a more manual way (unless someone has done the work already) to address this problem.

Craig

stancramer
Roundtable Fellow
Roundtable Fellow
Posts: 60
Joined: Sat Feb 07, 2004 10:34 am
Location: Washington DC

Post by stancramer » Thu Jul 10, 2008 12:06 am

I was in your shoes once, cbrenner. My solution was to follow the advice embedded in the title of this thread: Measure (which is a verb) the most active contract months.

It was good advice. I learned a huge number of things, just from the exercise of "thinking and doing". And then when I looked at my results, after "doing", they told me some crystals of wisdom. Admittedly I could have gotten these crystals sooner by hiring "old hands" in various markets and asking them a bunch of questions. But, (a) I didn't have the money; and (b) how was I supposed to find experts in each of the (many!) markets I wanted to test?

The way I went about it, was to learn programming and then write a couple of programs to do the measurements. I'm not saying this is the only way, it is just the way that worked for me.

You may come to different conclusions and obtain different results. But MY results told me to EXCLUDE (not trade) quite a number of contracts. To give you a small taste, here are a couple examples. You can compare these to your own results and see whether we agree or disagree.

1. Exclude (do not trade) the August contract of Soybeans
2. Exclude (do not trade) the October contract of Cotton

There are many dozens of other examples; these are just two that naturally "pop out' when you use a custom software method of measuring the most active contract months.

Good luck, remember that the Turtle Masters loved to suggest "Do the Hard Thing",

SC

cbrenner
Roundtable Fellow
Roundtable Fellow
Posts: 50
Joined: Wed Aug 27, 2003 4:09 pm
Location: Washington

Post by cbrenner » Thu Jul 10, 2008 2:02 am

sluggo wrote: Users "Hiramhon" and "Bondtrader" suggested and implemented and uploaded to this website a cute idea, here: viewtopic.php?p=6203&highlight=cleven%2A#6203
I followed this link to what user Hiramhon suggested back a few years ago (Mon Feb 09, 2004):
Hiramhon wrote: Let me suggest an experiment. Configure your data software (I will assume CSI Unfair advantage) to produce a continuous contract which incorporates all twelve tradeable monthly contracts of Crude Oil futures. Click with the mouse until you see twelve X's in the upper left panel, selecting all twelve monthly contracts. Give this continuous contract the temporary name Crude-12. Run your trading system on Crude-12 and capture its resultant profits and statistics.

Now reconfigure your data software to produce a continuous contract which ONLY includes the six contracts GJMQVZ (Feb, April, Jun, Aug, Oct, Dec). Give this continuous contract the temporary name Crude-6. Run your trading system again, on Crude-6, and capture its resultant statistics.

Compare and contrast the two trading system outputs. Crude-12 versus Crude-6.

(Why Crude Oil? (a) because it has contracts for all twelve months of the year, and all of them are reasonably liquid; (b) because all of the systems within Veritrader (the sponsor of this website) achieve excellent profits when trading crude oil)
…
I also did even versus odd Crude oil contracts and 50% allocation to odd contracts and 50% to even contracts. I've attached the results below.

The odd months show a slight increase in performance and the 50/50 allocation shows double the amount of trades but no material increase in performance. So the conclusion. Odd vs. Even vs. All. Appears to be little difference .
Attachments
Crude Test.PNG
Crude Test.PNG (39.43 KiB) Viewed 6211 times

cbrenner
Roundtable Fellow
Roundtable Fellow
Posts: 50
Joined: Wed Aug 27, 2003 4:09 pm
Location: Washington

Post by cbrenner » Thu Jul 10, 2008 2:15 am

stancramer wrote:I was in your shoes once, cbrenner. My solution was to follow the advice embedded in the title of this thread: Measure (which is a verb) the most active contract months.

It was good advice. I learned a huge number of things, just from the exercise of "thinking and doing". And then when I looked at my results, after "doing", they told me some crystals of wisdom. Admittedly I could have gotten these crystals sooner by hiring "old hands" in various markets and asking them a bunch of questions. But, (a) I didn't have the money; and (b) how was I supposed to find experts in each of the (many!) markets I wanted to test?

The way I went about it, was to learn programming and then write a couple of programs to do the measurements. I'm not saying this is the only way, it is just the way that worked for me.

You may come to different conclusions and obtain different results. But MY results told me to EXCLUDE (not trade) quite a number of contracts. To give you a small taste, here are a couple examples. You can compare these to your own results and see whether we agree or disagree.

1. Exclude (do not trade) the August contract of Soybeans
2. Exclude (do not trade) the October contract of Cotton

There are many dozens of other examples; these are just two that naturally "pop out' when you use a custom software method of measuring the most active contract months.

Good luck, remember that the Turtle Masters loved to suggest "Do the Hard Thing",

SC
Yep, this is about the path I was/am planning on taking if I can't "cheat" off anyone. :lol: At the moment I am trying to think through the best tool(s) to test the scenarios most effectively and efficiently.

Clearly, creating lots of testing scenarios with TB is one option but building and managing a plethora (probably 100's) of unique data test files (created through UA) seems hellish. :twisted:

I think I need to sleep on this one...

Cheers,
Craig

sluggo
Roundtable Knight
Roundtable Knight
Posts: 2986
Joined: Fri Jun 11, 2004 2:50 pm

Post by sluggo » Thu Jul 10, 2008 8:55 am

cbrenner wrote:The odd months show a slight increase in performance and the 50/50 allocation shows double the amount of trades but no material increase in performance. So the conclusion. Odd vs. Even vs. All. Appears to be little difference .
That sounds like a summary of the data, rather than a conclusion: I ran one test, of one system, on crude oil only. I found that the four options Even6, Odd6, All12, EvenOddBlend gave approximately the same raw profit.

I would have supposed that a conclusion would be a final choice and the rationale supporting that choice.

I was expecting to see words like "notoriously bad fills in New York markets" and "assumed slippage in simulation versus actual slippage in real trading" and "trader workload". It's yet another reminder that expectations often go unfulfilled :o

cbrenner
Roundtable Fellow
Roundtable Fellow
Posts: 50
Joined: Wed Aug 27, 2003 4:09 pm
Location: Washington

Post by cbrenner » Thu Jul 10, 2008 1:29 pm

sluggo wrote:That sounds like a summary of the data, rather than a conclusion: I ran one test, of one system, on crude oil only. I found that the four options Even6, Odd6, All12, EvenOddBlend gave approximately the same raw profit.

I would have supposed that a conclusion would be a final choice and the rationale supporting that choice.

I was expecting to see words like "notoriously bad fills in New York markets" and "assumed slippage in simulation versus actual slippage in real trading" and "trader workload". It's yet another reminder that expectations often go unfulfilled :o
Sluggo-

A bit harsh, eh? Yes, you are correct in my use of the word conclusion although I think you may have been a bit too literal in your review. My intention or maybe the spirit of what I was saying wasn't to express any final conclusions. It WAS mainly to present a summary of the results whereas I used conclusion to represent the completion of this specific and simple test (which is the test that User Hiramhon suggested per my previous post). I’ll try to be more prescriptive with my word choices in cases such as these to avoid confusion. May I suggest that you also step back a bit before you judge?

In any case, I actually haven't yet concluded anything globally except that even more investigation needs to happen. Quite honestly, this has just caused me to ponder why these results turned out the way did and see if they hold true under various other conditions or is this mainly an anomaly tied to the respective test conditions. Much work still needs to be done.

Clearly, the investigation, exploration and development of trading systems is much like the complexities of software development (and obviously sometimes includes writing code). A solid specification and architecture needs to well thought out in advance; you need to be well organized and compartmentalize your efforts; there are many factors (both internally and externally) that need to be considered that can impact the system; one small change or bug fix can cause a ripple effect which can break something else, etc. etc.

Sometimes it does feels like you’re the Little Dutch Boy who is putting his finger in the dyke only to find that the leaks keep coming and that you are running out of fingers. :shock:

Craig

Post Reply