I was discussing the various ways one might go about this with a colleague today and decided to post our conclusions here as it may generate some interesting ideas or perspectives on the various approached one might take to solve this. Even if there is currently no solution, it is at least intellectually stimulating.
------------------------------------------- I am going to try and explain the various problems I have encountered while trying to do this manually. Let's assume the following discussion is only using 2 systems and with $100k in equity. There are two main ways to combine systems. One option is each has its own equity pool and the other is they share an equity pool. When using most risk management methods, most systems are rarely fully invested, which means the cumulative total of all the systems are not fully exploiting available capital. When sharing an equity pool, available capital is more efficiently utilized. An example, System A is 30% invested on day X with with a cumulative expectancy of .25%. System B is 40% invested on day X with a cumulative expectancy of 1%. If each was trading their own equity pool, expected profit on day X for: System A = ($50,000 * .3 * .0025) = $37.50 System B = ($50,000 * .4 * .01) = $200.00 Total = $237.50 If each system was trading from the same equity pool: System A = ($100,000 * .3 * .0025) = $75 System B = ($100,000 * .4 * .01) = $400 Total = $475 Think a moment about the cumulative affect this would have over many years. Now, because one system was 30% invested and another was 40% invested, trading from the same equity pool still only uses 70% of the capital vs. only 35% when trading from separate pools. However a problem arises if system A is 65% invested and system B is 40% invested unless you are using margin and for the sake of testing, we are not. One needs a way of defining a "position score" that will prevent the combined systems from using too much equity but allowing the system to still take the "best" trades from the systems. Now, even if you wanted to trade from separate equity pools, you would still rebalance everything every once in a while, which is not possible when testing them separately. Another example: After one year System A makes $10,000 and System B makes $25,000. Without rebalancing, System A would be trading from a (($100,000/2)+$10,000) $60,000 pool while system B would be trading from a (($100,000/2)+$25,000) $75,000 pool. With yearly rebalancing, each system would simple trade the next year with a ($100,000+$10,000+$25,000)/2 = $67,500 equity pool. This was a yearly rebalance but the discrepancy would get even worse with daily compounding over many many years. The result would be at the end of the test, the weaker system would have almost no affect on the overall results. This was confirmed in excel. The conclusion is that to effectively test multiple systems together, one needs a mechanism within the backtester itself to not only run multiple systems, each with their own internally specified entry, exit, stop, and position sizing criteria (and all the various settings and options associated), but also apply position score filtering on all the cumulative signals generated by all systems and/or equity pool rebalancing if the developer chooses to have each system run on its own equity pool. --- In [email protected], "bh.hicks" <bh.hi...@...> wrote: > > I agree. Normally I like to develop the systems themselves independently and > the only variables that would be optimized when combining them are the > position scoring and weighting of the different systems against one another. > > > --- In [email protected], "dloyer123" <dloyer123@> wrote: > > > > Watch out for one trap I ran into. > > > > If you are developing a portfolio of trading systems, it might seem like a > > good idea to optimize them all together. > > > > But, there are two problems: > > * It takes a long time, optimizing the parameters of each system at the > > same time, even with genetic algos to search the solution space > > * More importantly is greatly increased curve fitting. > > > > So, it is much better to have 3 systems with 1 or two optimizable > > parameters each, than one huge composite system with 6 optimizable > > parameters. > > > > If there where one feature I would like to have in Ami, other than built in > > multi core support, it would be a built in measure of walk forward > > efficiency. That is a measure of the degree of curve fitting of a system. > > See Pardo's recent book for more information. > > >
