Benoit, That is an interesting approach. I am just getting familiar with AmiBroker as I have decided to migrate away from another platform so I will need to do a little work to get up to speed to see if this method does what I need. Thanks for the suggestion though, I will certainly look into it.
--- In [email protected], "benoitek1" <benoit.march...@...> wrote: > > Hi, > > I fully agree. A system based on multiple uncorrelated systems must share an > equity pool. > Here is the solution I more or less use : > > at system level : > ----------------- > 1. create a watchlist which will own 1 composite symbol per symbol under > backtest > 2. in custom backtest, fill composite symbol (for each bar) with : > nop/buy/sell, position size, position score, buy/sell price > > at multiple system level : > ----------------- > 1. apply a "position score" coefficient to each independant systems > 2. backtest the watchlists owning the composite symbols and trade the one > with the best "position score" > > It can be time consuming but this is not a real issue at this development > stage. > > What do you think ? > > Thanks, > Benoit > > --- In [email protected], "bh.hicks" <bh.hicks@> wrote: > > > > 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.hicks@> 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. > > > > > > > > > >
