>snip< As I wrote it is not technical problem but human problem. The problem of understanding.>snip<
Unfortunately you can not 'dumb down' the tools to suit the lowest common denominator. If you do all that will happen is that someone will come along and set the bar even lower. The tools supplied must stand up to empirical tests or else you (AB) will lose credibility with knowledgeable traders and issues with features built on a weak foundation will compound into the future. Similarly if you don't supply the tool at all AB will lose credibility. The only solution is to implement what is technically correct and educate users 'up' to the mark ... I understand that attrition rates and inertia etc are very demotivating with regard to this policy. >snip< In this case you MUST resolve problem on *when* and *how* to rebalance >positions 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.>snip< The example solution you mention is only relevant to long term traders. It is not a big issue for long term traders because they can afford to pay the commissions involved in adjusting holdings for rebalancing purposes. There are so many different types of users, and so many strategies, that it is up to users to define a workable stategy for their own use e.g. depending on the average time in trade for the system, and the typical 3 StDev volatility, users can estimate the max possible gain (with 99% accuracy) and preserve enough cash to use for rebalancing, if that gain eventuates. Isn't it your task to just supply the flexibility, in the feature, to allow all users to implement the rebalancing when and how they like (subject to reasonable use) and leave the rest to us? >snip< b) multiple-system portfolio backtesting where portfolios have more than >one symbol and possible overlap between symbols traded.>snip< The first thing is that PositionScore is not a good strategy. If system A has two signals at the same time and an additional rule (the position score rule) makes a significant distinction between them then the additional rule makes it a new system and it should be backtested separately. If the position score rule did not make a significant difference then the trader wouldn't use it in the first place. I also think that the AB backtester model is making this type of implementation more difficult than it needs to be. Off the top of my head I think this is how it could be handled: - no money management is involved - all signals, for all symbols, are quantified (user defined N is achieved with the least amount of data consumption and they are in the most efficient format for making empiricial MM decisions) - all open trades are standardised to the BT timeframe - no trade bars are filled with the cash rate of return i.e. the cash that was in the trade is not considered to have returned to the cash pool (no trade bars are filled with cash rate) - cash return is, say 6%/252 trading days in a year So for system A in a 5 bar backtest (say daily): Note that the trade series records open position value at the end of each bar. sym1 trade series == 1%, -0.5%, 2%, cash rate, cash rate; sym2 trade series == cash rate, -1%, cash rate, 3%,cash rate; SystemA typical return == bar by bar average of ROC for all symbols in the universe. At the portfolio level (on a 5 bar basis): Note that this is approx only - the cash rate is treated as if it is zero for this example. 33% Cash 33% System A typical return == 0.5, -0.75, 1,1.5,cash; 33% System B typical return == -0.8, cash, 2,-3, 2; If no signal, for a system, is available from any symbol then the system is in cash for that bar. Opt f is calculated, only at a system level and for all of the bars, including the cash day. This way the true opportunity cost of 'bars out of trade' is accounted for by the owner system. Opt f is used to calculate the optimum allocation for the three classes of investment in the 'system portfolio'. The user has to manage the trade off between the cash component, systems used, time out of trade etc and the cost of rebalancing versus the cost of trading at a less than optimum porfolio and/or system capital allocation (too much going on there, all at the same time, for a human being to handle!). In this model the trades that become available for each system are not considered to be unique (none has more or less significance than another) ... randomness rules the trade sequence. So I don't consider that rebalancing is the difficult issue ... it is the choice of the multi-system development model that is the hard decision. --- 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 > > > > > > >
