|
PureBytes Links
Trading Reference Links
|
> 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.
PositionScore is not the only way to do it and I don't think it is the optimal method anyway.
Each of your systems, separately, has a mathematically optimum stake (as a % of your capital).
Combined systems have a mathematically optimum allocation (as a % of your capital).... this may take the individual systems away from their optimum but the collective benefit compensates for this.
It is a personal choice if you want to run at less than optimum at the portfolio level ... calculating the portfolio optimum will return a number that tells you how much you are paying i.e. you have to accept less than opt returns for peace of mind (less risk) ... undoubtedly having some of your capital in cash represents less return and less risk.
If you do decide to change the % in cash, including going to zero cash, then the way to that empirically is to recalculate the allocations.
Youy can't guess the opt allocations ... the only way to do that is to iterate through all possible allocations (optimize relative position sizes)
Position score has nothing to do with it, in fact, in some cases a portfolio that includes a system with negative expectancy can be more efficient than others with all positive expectancy systems.
> 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.
I am not certain that your model is correct or that it would be accepted by the majority.
If Tomaasz ever does implement multiple system backtesting then I expect that he will have to do it in a generic way so possibly many of us will end up being unhappy.
I am suggesting to you that Vinces/Markowitz's model is an empircal portfolio model that could be implemented by any average AB user (it does not involve extremely difficult logic). Implementing it at the core metric level (trade series, Geometric Mean, optimal f) is a lot easier, and more efficient/accurate, than mucking around with integrated Money Mangagement in an off the shelf BT.
--- In amibroker@xxxxxxxxxxxxxxx, "bh.hicks" <bh.hicks@xxx> 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 amibroker@xxxxxxxxxxxxxxx, "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 amibroker@xxxxxxxxxxxxxxx, "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.
> > >
> >
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|