Since we have had such a big discussion and it is linked/tagged for future reference, by searching .... FTR:
Why do I want to analyze all trading signals? - I want to collect buy/sell signals as pairs i.e. all potential trades independent of MM decisions. - in AB's standard BT default the paired signals only become a trade when they are allocated funds, via Money Management rules ... this biases analysis to the trades actually taken rather than the ones that could have been taken. - considering a BT on one symbol only ... if we do not restrict entries, via MM settings, we can enter a new trade, after we exit the previous trade, but we can not take all signals. a) Using this 'limited' record biases the results if by chance the MM controlled process selected some wild outliers (this is just the argument for using a larger N of trade samples and looking at the trade series before MM analysis in case we want to exclude some wild outliers from our analysis). b) We don't learn as much about our system if we only look at the outcomes from a MM controlled BT ... we have more info to cross reference if we look at the trade series itself. c) If we don't consider all trades we do not have the info we need to decide if there is dependency in our trading system. Dependency is the basis for trading the equity curve .. if we don't have trade dependency we can forget about trading the curve (we can get this info other ways but if we look at our series to see if the signals that occured when we were already in the trade, perform better than the signals that occured after a losing trade we have some additional info that we don't get from MM controlled trade series). d) Even without wild outliers in our trade sample, limiting the analysis to a smaller N just increases the chances that fortuitous selections will bias our results and data is precious (we only have 1 - 2 decades of algorithmically traded data to analyze). Why waste it, by leaving trades behind, when we don't have to? e) if we want to perform optimization runs, for various PositionSizes, then we need to do that using the same trade series i.e. all of the trades (the population) and not some of the trades (the sample). For example: - we can calculate optimalF, for any trade series, by iteration (this is quite quick,in comparision to optimizing by parameter searching, because we are narrowing the range each iteration). - theoretically, if we optimize our PositionSize, by parameter searching, we should arrive at optimalF (as calculated), providing the trade series samples are identical. We won't arrive at the correct optimalF, by massive parameter searching, if we 'allow' MoneyManagement processes to selectively pick out a portion of the total signals. If we did that we would be optimizing on a different trade series every time we change the PositionSize setting (unless we restrict ourselves to optimizing on one symbol). There are other issues to consider too; such as equalization across time and standardization between instruments (very hard to manage when an MM process is allocating $ to a trade). As we add symbols to our trading universe (tested watchlist, portfolio of data, instruments we trade) these issues are compounded and then compounded again if we want to make trading system comparisons, across that data. If we collect all of the paired signals, on a symbol by symbol basis, and save them we can then: - test various MM regimes, and replicate them if necessary, ON A STANDARDIZED BASIS i.e. the performance of the MM regimes is compared on exactly the same series of trades. - look for new opportunities e.g. how did my system perform on symbol A compared to symbol B OR on sectorA compared to sectorB - look for opportunities to perform our analyzes mathematically (if we can find some then in future we could get the same, or similar results, without massive analysis ... perhaps we can use maths formulas to provide approximate indication of equity outcomes in fast RT charts). Re optimalf: - theoretically we are all trading at some factor of f - we should never trade above f == 1 - 1 is the theoretically optimal allocation of funds - if we want to trade conservatively trade at fractionalf Re non correlation: - I am probably OK with portfolio models that include correlation factors (how else can we possibly do it?) .. I feel I should reassess what non-correlation is OR look for new places to find it. I didn't follow every single move, in the 2008 market 'crash' closely but looking on, as a casual observer, it seems that the only non-correlated assets were cash, treasuries and the US dollar. Did anyone notice any others? --- In [email protected], "brian_z111" <brian_z...@...> wrote: > > Thanks, > > It is very helpful to me to find out how traders are actually doing it > (instead of just talking about it, as Ang points out). > > I am working on some AFL code to present the trade series% as a matrix (not > for my grand scheme ... just a limited first version of the first stage). It > is intended for comparitive evaluation of syatems and MM regimes, either > within AB OR for export. > > May be we have some common ground in the need for an export format.... hence > the questions. > > > >I personally prefer comparing percentages than absolute dollars or >points > >because when working with futures, each instrument can have a >different > >tick size, point value, and margin. > > Yes % is what I am working with, to equalize historical returns with current > returns and to standardize across instruments. > > > When trading futures, open trade drawdown is very important because >trades > > are "marked-to-market" every day. Margin requirements must >be met each > > day for overnight positions. > > Understood. > > That is the hard part. > I am biased to closed trades but I guess the majority of traders want open > trade returns or at least want to consider them. > Don't know if I can manage that, because it is a tougher AFL challenge ... > that will be the last thing I try .. one step at a time. > > > When you export the trade series: > > - what information do you need with each trade? > > My initial aim is to get trade%, bars in trade, bars out of trade, maybe the > entry and exit date if needed. > > > In AB's BT, AFAIK, the default is to only enter one trade at a time so > normally the BT reports only for those trades that made it past the one trade > only AND MM filter. > I am interested in getting all trades. > Are you interested in all trades and/or getting all trades? > > My knowledge of the AB's BT is limited and so far I haven't used the CBT. > In AB's BT I find that if I want to get a report on as many trades as > possible then I have to manipulate MM, or perform a series of individual BT's > on a symbol by symbol basis. > > In the method I am having a go at I have started out by: > > - counting all of the buy signals > - make several passes over the data, collecting trade pairs (buys/sells) > until I have them all ... so far I am getting most of them with a simple buy > and simple % profitstop but it is early days (trades collected == approx > initial count of all buy signals. > > Are you interested in all trades? > What are your thoughts and experiences on this. > > Are you doing a Portfolio BT with one CSV export for the lot OR several > individual BTs' with many exports? > > > I am not endorsing MSA because I don't know much about it but I am interested > in it ... now that you tell me you are using it and what you are using it for > I will put a revisit to MSA on my to do list. > (I am biased to my own productions because then I now everything about them > and I know how far to trust them). > > Last time I looked I had an issue with the fact that MSA did not account for > the trades in the order that they occurred ... I think he has changed that > now (I used to think this was important although I don't now). > > What is the minimum requirement for their format i.e.does it use any info > besides trade series% to evaluate comparitive MM results. > > You said you can do 90% of what you want in AB. > What do you need for the last 10% ... the short list :-) > Do you want to do it here or are you just as happy to go to MSA? > > Thanks once again. > > > Ang - what I am trying to say is one size doesn't fit all. > We have been offered many solutions so far (Paul, Howard, Graham, Mike, > Tomasz, Dave's, Patrick's off the shelf R portfolio solutions, my so far > insubstantial model) but still many want something else? > > Mike and Tomasz .. thanks. I will study your suggestions. > > > --- In [email protected], "dbwyatt_1999" <dbw451@> wrote: > > > > Hi Brian, > > > > Below are responses to your post: > > > > > I assume you mean 12 systems? > > Yes, 12 systems; I use the terms system and model interchangeably. > > > > > So you are running all 12 systems over the same data and timeframe to get > > > the trade series for each? > > I run all 12 systems are over the same portfolio of data. I have a primary > > timeframe, but I'm evaluating several timeframes. > > > > > Are you collecting the trade series as $, points or %? > > I'm not sure what you mean. I think of trades as instruments, entries, > > exits (stop and sometimes a target), and trade sizes. Dollars, points, and > > percentages are different views of the trade output. I personally prefer > > comparing percentages than absolute dollars or points because when working > > with futures, each instrument can have a different tick size, point value, > > and margin. > > > > > How do you export to a database? > > From Automatic Analysis, File->Export creates a comma separated file that > > can be imported into a database table. I use MS Access primarily because I > > have it available in my version of MS Office. > > > > > Do you find that open trade drawdown is important? > > When trading futures, open trade drawdown is very important because trades > > are "marked-to-market" every day. Margin requirements must be met each day > > for overnight positions. > > > > Regards, > > > > David > > > > > > --- In [email protected], "brian_z111" <brian_z111@> wrote: > > > > > > Hello David, > > > > > > Thanks for keepting discussion on this issue going. > > > > > > I tried MSA a few years back .... thought it was one of the better tools > > > around. It seems to have developed a bit since then. > > > > > > It has been reported in this forum before (as a MonteCarlo tool). > > > > > > > > > A couple of questions to help me with my own private efforts: > > > > > > > I faced the same issue except I have 12 models > > > > > > I assume you mean 12 systems? > > > > > > > I decided to run my models separately in AmiBroker and then export the > > > > trades to a database. > > > > > > So you are running all 12 systems over the same data and timeframe to get > > > the trade series for each? > > > > > > Are you collecting the trade series as $, points or %? > > > > > > How do you export to a database? > > > > > > Which database? > > > > > > >The caveat is that MSA uses trade information for all it's >statistics > > > >and has no knowledge of the chart data used to create >those trades. > > > > > > IMO using mathematical models, based on the trade series, considered as > > > the return of the investment, is the best way to compare portfolio > > > outcomes. As Howard pointed out in one of his posts, we do have to be > > > very careful when making assumptions based on non-correlation because it > > > can disapear quite quickly (I believe non - correlation, between > > > instruments and markets etc, has been falling, over the last decade or > > > two, because of the growth in algorithmic trading and/or analysis.) > > > > > > >So statistics like Max System Drawdown are different than the much > > > >more accurate AmiBroker MDD because AmiBroker can look at each chart > > > >bar and determine the actual intra-trade MDD while MSA only knows >the > > > entry and exit prices of each trade. > > > > > > Do you find that open trade drawdown is important? > > > I tend to think that it is irrelevant if the system uses stops .... any > > > intratrade loss must always be less than the stop loss or the trade would > > > have closed, on stop? > > > > > > I am also inclined to the view that intratrade equity is a hypothetical > > > figure ... the outcome of the trade isn't known until it is closed. > > > > > > > > > > > > > > > Here is the link to Howard's post that I referred to prev. > > > He says that he is including Portfolio Construction in his next book > > > (Advanced AB) ... due out at the end of 09. > > > > > > http://finance.groups.yahoo.com/group/amibroker/message/138075 > > > > > > > > > KEYWORDS > > > > > > OPTIMAL PORTFOLIO CONSTRUCTION MODELING > > > > > > --- In [email protected], "dbwyatt_1999" <dbw451@> wrote: > > > > > > > > Soham, > > > > > > > > I faced the same issue except I have 12 models that use a portfolio of > > > > 27 futures instruments. The issues involved with running multiple > > > > systems simultaneously are much more difficult than dividing the system > > > > logic by symbols or watchlists. For example because you are > > > > considering trending and counter-trending systems, there is the > > > > possibility of being long and short in the same instrument in two > > > > separate models each with a different trade size. I tried combining my > > > > models in AmiBroker, but my custom stop handling and dynamic position > > > > sizing just became a nightmare to manage. After reading through most > > > > of the multiple systems threads on this forum, I started thinking about > > > > alternative solutions. > > > > > > > > I decided to run my models separately in AmiBroker and then export the > > > > trades to a database. From there I would write a simplistic > > > > back-tester that would step through the combined trades, recalculating > > > > the trade quantities using a shared equity pool. At this point I did > > > > some googling to see if there was any Excel, or C# libraries, or any > > > > other software that would give me a simplistic back-tester framework. > > > > I thought about feeding the trades back into AmiBroker as signals, but > > > > that would amount to a lot of AFL code to handle the models by scaling > > > > in and out positions with the possibility of managing long and short > > > > positions simultaneously. Also I want to vary the number and mix of > > > > models I test in the future, so the AFL programming would have to be > > > > generic which makes the task even more daunting. > > > > > > > > Anyways through my googling, I found a software product called Market > > > > System Analyzer by Adaptrade (www.adaptrade.com) that already had > > > > implemented the approach I was pursuing. The primary purpose of the > > > > MSA software is to explore position sizing models (all of which I think > > > > can be written in AmiBroker). I'm able to import my AmiBroker trades > > > > into the MSA software. MSA can treat my 12 models as a single > > > > portfolio and generate a combined equity curve and other back-tester > > > > statistics from a shared equity pool. It recalculates trade sizes > > > > (i.e. shares) based on the position sizing model selected. The caveat > > > > is that MSA uses trade information for all it's statistics and has no > > > > knowledge of the chart data used to create those trades. So statistics > > > > like Max System Drawdown are different than the much more accurate > > > > AmiBroker MDD because AmiBroker can look at each chart bar and > > > > determine the actual intra-trade MDD while MSA only knows the entry and > > > > exit prices of each trade. > > > > > > > > MSA has been a decent solution for me to fill a void that I wasn't able > > > > to complete with AmiBroker. Instead of spending days or weeks writing > > > > my own multiple system handling logic, within a few hours I had all my > > > > 35,000 trades loaded into MSA and was creating the combined system > > > > statistics I was after all without any programming (other than a > > > > database query to export the AmiBroker trades by symbol into an MSA > > > > import format). > > > > > > > > I'm weary to bring up another software product on the AmiBroker user > > > > forum especially since AB can do about 90% of what MSA does, but in > > > > this case I have not found anything posted that has given me a doable > > > > solution to combining multiple back-testing trading systems. > > > > > > > > Best of luck with your system development. > > > > > > > > Regards, > > > > > > > > David > > > > > > > > --- In [email protected], "Mike" <sfclimbers@> wrote: > > > > > > > > > > You could probably use the same technique as is used for pairs > > > > > trading. Specifically, check for the name of the symbol and apply the > > > > > applicable logic. > > > > > > > > > > http://finance.groups.yahoo.com/group/amibroker/message/134492 > > > > > > > > > > If you don't want to have a bunch of if (Name() == ...)statements, > > > > > you could probably add some symbols to watchlist1, the others to > > > > > watchlist2, all of the above to watchlist3. Then use InWatchList() in > > > > > your code instead of checking the name. You would run your > > > > > backtst/optimization/etc. on watchlist3. The danger of that though is > > > > > if you add a symbol to watchlist3 but forget to also add it to either > > > > > watchlist1 or watchlist2. > > > > > > > > > > if (InWatchList(1)) { > > > > > ... // Strategy 1 > > > > > } else if (InWatchList(2)) { > > > > > ... // Strategy 2 > > > > > } > > > > > > > > > > Any custom money management would probably have to be implemented in > > > > > custom backtester code. > > > > > > > > > > Mike > > > > > > > > > > --- In [email protected], "Soham" <sohamdas@> wrote: > > > > > > > > > > > > Any help on this? > > > > > > --- In [email protected], "Soham" <sohamdas@> wrote: > > > > > > > > > > > > > > Hello Everyone, > > > > > > > > > > > > > > I believe, I have seen this question here itself or one of its > > > > > > > forms. But given the "fantastic" search results of Yahoo groups, > > > > > > > I am posting this once again. > > > > > > > > > > > > > > Is there any method, to simulate multiple strategy on a portfolio > > > > > > > level?For example, consider I want to use a trend following > > > > > > > system for Cotton, Coffee, Copper, EuroDollars and FAZ. While, I > > > > > > > want to "simultaneously" simulate a trend fading system for > > > > > > > SPX,NDX and RYDER. > > > > > > > > > > > > > > Is there any way to do it? > > > > > > > > > > > > > > And very related to this stuff, the one possible way, I can think > > > > > > > of is, using multithreaded programming. Is it possible? > > > > > > > Interfacing say C# with Ami and handling the two strategies with > > > > > > > their own money mgmt algos, and instruments etc? > > > > > > > > > > > > > > It is to be reminded that, they draw their "juice"[$$$] from the > > > > > > > same account. > > > > > > > > > > > > > > Thanks, for any light on this > > > > > > > Soham > > > > > > > > > > > > > > > > > > > > > > > > > > > >
