I'd like to stress again what I wrote in http://finance.groups.yahoo.com/group/amibroker/message/137973
There are 2 important linked points 1. the same logic used in portfolio backtesting should be used in multi-systems portfolio backtesting. Different average holding periods are therefore not an issue since even with a single-system portfolio I can hold a position much longer than another but that position is not preventing the system to trade other names with lower holding periods WHEN USING PROPER POSITION SIZE. 2. you don't assigne X% of capital to system A and Y% of capital to System B so there is no need to rebalance anything. I should assign a proper positionsize of the equity line every time I get a signal whatever system it comes from - for instance I can always take a 2% position on every signal no matter if it comes from system A or B if I'm not supposed to potentially get more than 50 signals at the same time. I can even use different position size for each system but what is important is to never reach 100% of the equity when all signals could take place at the same time. Let me make a simple example that can clarify my view on this. Let's say I have 2 systems applied to a universe of 30 stocks. I must use a proper PositionSize (this is essential), in this case SetPositionSize( 100/(30*2), spsPercentOfEquity) = 1.66% of the equity poll and no system will prevail on the other whatever holding period they have. I hope this can help, paolo --- In [email protected], "Tomasz Janeczko" <gro...@...> wrote: > > As I wrote it is not technical problem but human problem. > The problem of understanding. > > You simply don't see that there is BIG difference between: > > a) multiple-system on individual symbols > which is currently possible and quite easy in fact > and described back in 2006 > http://www.amibroker.com/kb/2006/09/29/how-to-set-individual-trading-rules-for-symbols-in-the-same-backtest/ > > b) multiple-system portfolio backtesting where portfolios have more than one > symbol and > possible overlap between symbols traded. > > In this case you MUST resolve problem on *when* and *how* to rebalance > positions between systems. > Without that you would end up with trading only "winning" system after some > time, because worse > systems would run out of money. Why? Simply because if winning system does > not go to the cash > but opens other positions or reverses positions the other systems would not > get the chance > to use the cash from winning trades of the other system, because at the time > when worse > systems want to open positions, the cash from winning system would be > allocated to the new > trades of winning system, simply because entry/exit moments are (in most > cases) not synchronized between systems. > > Therefore one needs to have a method of reallocating equity to restore > original allocation percentages > between symbols. The simplest method to do is to rebalance periodically. For > example quarterly. > You can close all open positions quarterly and then re-open them with > corrected position sizes > to reflect ideal (desired) balance between systems. > > But that is just one (simplest) method of doing rebalancing different system > portfolios. > > Best regards, > Tomasz Janeczko > amibroker.com > ----- Original Message ----- > From: "benoitek1" <benoit.march...@...> > To: <[email protected]> > Sent: Thursday, May 07, 2009 12:00 PM > Subject: [amibroker] Re: testing multiple systems simultaneously > > > > Hi all, > > > > I also do believe that this question is easy to deal with. I do believe > > that because I (badly) did it as I showed in a previous > > post (http://finance.groups.yahoo.com/group/amibroker/message/137900). > > > > An integrated solution made by Tomasz could consist in : > > > > 1. adding an afl function "addSystem (<ts_afl_main_file>,TsPositionScore)" > > to add all the independant Trading System (TS) to make > > THE Multiple Trading System. The TsPositionScore is a global PositionScore > > attached to each TS. I attached an associated afl > > sample below. > > > > 2. adding a MultipleSystemBacktest which would consist in : > > 2.1 backtesting each system independantly and storing all the issued > > Buy/Sell signals (rather than the trades themselves) with > > their associated Buy/SellPrice and their PositionScore as coded in the TS. > > 2.2 backtesting the stored signals using as PositionScore a composite > > PositionScore (MtsPositionScore) based on the TS > > PositionScore (the one you know) and the TsPositionScore (the one globally > > attached to TS) > > > > I feel like Tomasz is almost ready to go ahead :-). Could we all of us try > > to converge to completly convince him ? (ie could we > > all of us discuss on a concrete implementation rather than philosophiing on > > the concept - which is very nice sometimes but also > > slows down the execution some other times) > > > > ----MultipleTradingSystem afl code--- > > addSystem (..\TrendFollower\ts1_main.afl,1) > > addSystem (..\MaCrossing\ts3_main.afl,2) > > addSystem (..\Reverse\DDOptimized\ts2_main.afl,3) > > ----end of MultipleTradingSystem afl code--- > > > > To be complete on what I've done, I did not find THE optimized equation to > > generate the MtsPositionScore. But I'm sure this is > > just due to my personal limitations ;-) > > > > > > --- In [email protected], "Paolo Cavatore" <pcavatore@> wrote: > >> > >> First of all I'd like to say this discussion is very interesting and a key > >> point according to me. > >> > >> Secondly I do believe the issue is much easier than what many are > >> suggesting. > >> Multiple Systems testing should be considered with the same logic that > >> Portfolio backtesting is using with underlying securities. > >> Therefore I believe a new AB feature would be required. This feature > >> should ask the user which AFL systems combine and then the > >> user can simply use standard Portfolio functions like: > >> -PositionSize (this would take care of Sizing each position and could be > >> tied up to each single system) > >> -PositionScore (this would take care of multiple signals coming from > >> different systems) > >> -MaxOpenPositions (to avoid having several open positions due to different > >> systems giving a signal at the same time) > >> > >> Furthermore I fully agree with ang_60 that when you use just "one equity > >> pool", you don't assigne X% of capital to system A and > >> Y% of capital to System B: so, there's no need to rebalance anything. > >> > >> I cannot imagine anything easier than that and there wouldn't be any need > >> to rebalance actually. > >> > >> paolo > >> > >> --- In [email protected], "ang_60" <ima_cons@> wrote: > >> > > >> > --- In [email protected], "Tomasz Janeczko" <groups@> wrote: > >> > > > >> > > Hello, > >> > > > >> > > The main problem is not technical but "human" - i.e. I guess that > >> > > everyone > >> > > that would be interested, would like to have rebalancing implemented > >> > > differently. > >> > > The devil is always in the details. > >> > > > >> > > So, let us discuss *your* preference. Let assume the following: > >> > > > >> > > a) we have 2 systems, and initially system A gets 60% of initial equity > >> > > and system B gets 40% of initial equity > >> > > > >> > > >> > > >> > Hi everybody, > >> > > >> > maybe it's just me but I think this is a great discussion. > >> > > >> > Just some thoughts: > >> > > >> > 1) when you use just "one equity pool", you don't assigne X% of capital > >> > to system A and Y% of capital to System B: so, there's > >> > no need to rebalance anything. > >> > > >> > You start applying position sizing rules to your entire capital as soon > >> > as Sistem A, B, .... N gives you a signal. > >> > > >> > You need to rebalance only when you start dividing your trading capital > >> > from the N system which - I concur wuth Hicks - is a > >> > less efficient way to use your money (providing both your systems have > >> > positive expectation) > >> > > >> > 2) That's the very same reason you cannot simply add N equity curve to > >> > do portfolio testing.... because when mixing in one > >> > account (as in the real life) signal from system A and system B AND > >> > increasing trading size with the closed profits, it's > >> > mandatory to take into account the chronological order of the combined > >> > series of trades. > >> > > >> > 3) Hicks, I'm pretty sure Graham can do it (provided you don't want to > >> > run system A on database A and System B on database > >> > B.... ).... but if you are a bit like me (I'm not a programmer turned > >> > trader..... I'm an investor that thinks his daytime is > >> > better spent when I'm not programming.... ) maybe you will find his code > >> > a little complicated, would any further manipulation > >> > be needed from you. > >> > > >> > > > > > > > > > > ------------------------------------ > > > > **** 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 > > > > > > >
