Traders' Roundtable

I ve been reading this forum thoroughly for many weeks now - I wanted to re-raise a topic that I cannot see has been covered in too many areas before.

There are many discussions about the merits of testing as larger portfolio of markets as possible over as long as possible - This is understandable - But given so many markets have only "come on line" in the last 5-15 years (i.e. Rubber / Palm Oil / Mini's , Milk, Mex Peso etc etc ) is it advisable to test all these markets in a test that goes back 30 years ? Surely in this instance you are not getting a true picture of the 30 year results ?
My conundrum was should I test on a basket of markets that have been in existence for 30 years in order to get a valid pointer as to how the system performance has changed and / or should I then apply new markets as they emerge and only test the whole system from the period these markets are added ?
If you take every market available today and run a 30 year backtest then obvioulsy the system will only be testing on half of these markets in the late 70's - does this then give a true 30 year reflection of the system ?
I personally preferr, to test a constant basket of markets that have been in existence from the start of the test to the end of the test and then look for a good system. Then I will try running it from, say 1998 until now including all the markets that have emerged in more recent years and see how it holds up on that period with those markets ?

Just wondering how other people approach this issue and drum up some thoughts on the whole area if possible.
Chris

Hypothetically, suppose your job is to figure out how to modify a system (or a suite of systems) to "deal with" a time-varying portfolio. Some markets die (for example, Spanish Bond, Notionnel Bond, MATIF PIBOR, GNMAs, T-Bills, NYFE, MuniBonds) and other markets are born (Volatility Index, Electricity, ICE-WTI). Yet your job is to make a system or suite of systems, adapt to this environment.

Perhaps the beginning of the germ of an idea, might be to trade an infinitely large portfolio with medium largish risk per trade, BUT use heat-limiters to prevent overbetting. Such as in Thermal_BBBO. Perhaps this might decouple portfolio size from trading performance, a little bit or a lot.



Or perhaps not.

Sluggo - Yeah I like the thermal bbo and I like the idea of limiting heat per sector / group but as per my earlier postings I dont have the skills to program that and I cannot understand why the group risk manager is not working - the one that ships with TB Blox Builder - as I said before Ive got my GROUP 1 set to grains , currencies, meats etc - but it doesnt seem to make any difference if I set no markets per group or 30 markets - I still get the same number of trades - Where as I take your point that employing a programmer or paying TB to do some work for me - I only really want to know the Group / sector bit as I'm fairly up to speed with what else I want to know right now - Any help on how to set up the Futures info file to fit with your thermal bbo system would be appreciated - i.e defining groups/sectors - would be warmly appreciated
Chris

Chris67 wrote:Sluggo - Yeah I like the thermal bbo and I like the idea of limiting heat per sector / group but as per my earlier postings I dont have the skills to program that and I cannot understand why the group risk manager is not working - the one that ships with TB Blox Builder - as I said before Ive got my GROUP 1 set to grains , currencies, meats etc - but it doesnt seem to make any difference if I set no markets per group or 30 markets - I still get the same number of trades - Where as I take your point that employing a programmer or paying TB to do some work for me - I only really want to know the Group / sector bit as I'm fairly up to speed with what else I want to know right now - Any help on how to set up the Futures info file to fit with your thermal bbo system would be appreciated - i.e defining groups/sectors - would be warmly appreciated
Chris

Chris, you have seen Sluggo's free Thermal BBO system in the Marketplace, right, where you can see all his code, etc.? (Damn nice of him I say BTW.)

Maybe you were referring to transcribing the heat limiter to other sorts of systems, but the above chart is pretty much what I get when running Thermal with a large number of markets.

Leapfrog - thanks for your post - yes I agree a great blox by Sluggo and and kindly shared by him - As i said not having much luck in understanding the code !!! Im not the Worlds best programmer and will seek outside help - I just wondered if I was making a basic error in the set up of the futures info file in listing the categories such as Currencies / grains etc under Group 1 and then applying the bbo system to it ?
C

...suppose your job is to figure out how to modify a system (or a suite of systems) to "deal with" a time-varying portfolio.

Here's another idea: Start with garden variety fixed-fractional betsizing

• #Contracts = ((Total Accout Equity) * (A User Supplied Constant)) / ((Distance to Exit) * (BigPointValue))

and modify it, based on the total number of tradeable markets today. Maybe one or more of these Blox properties, in the denominator of the FF betsizing equation, would prove useful. They give you the ability to change the betsize based on the size of the portfolio, today. The portfolio might grow larger tomorrow, and you might want to adapt to this by using a smaller betsize.

It's a thought.

Sluggo's idea is a good one. Dynamically adjusting position size according to the number of markets available for trading can aid in keeping heat within a narrow range over long periods of time.

I have found I need to be a little wary of "system.tradingInstruments" in betsizing since this can vary fairly dramatically because of non-trading days for particular instruments. Particularly if you trade a lot of foreign markets.

I tend to use a 10 day high of tradingInstruments, something along the following lines: Does not take account of instruments which have ceased to trade over the 10 days but I would rather bet too low than too high.

Good point AFJ. A while back, I had written an alternate version of the "instrument.tradingInstruments" property which eliminates the "have price information for the current test date" condition. As a result, markets that are closed due to a Holiday (or weekend) are not excluded from the calculation. The Blox can be found here:

viewtopic.php?t=3828

Far slicker! Thanks for that.