There is no out of the box solution. But you have a number of ways to do this
kind of things. I will add one more suggestion.
Write a multiplexer function that would take in buy and sell signals as well as
position scores from 2 or more systems. and generate the a single buy/sell
signal pair that reflects your rules and priorities.
for example
function multiplexer(nBuy, nSell, mBuy, mSell, nPositionSocre, mPositionsCore)
{
// you can not use applystop in defining your Buy/sell signals
// do a for loop going through every bar, once a buy from either nBuy or mBuy
is encounter, do not accept any more signals other than a respective sell from
the same group, if both sigs arrives at the same bar, use positionscore to
decide.
// do the same with short and cover if you want.
finally VarSet("Buy", your buy signal), Varset("Sell", you sell signal)
}
--- In [email protected], "bh.hicks" <bh.hi...@...> wrote:
>
> 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.marchand@> 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.
> > > > >
> > > >
> > >
> >
>
