It allows you to alter the way the backtest is conducted...this should give you some decent background on the functionality:
http://www.amibroker.com/docs/Houston2.pdf ________________________________ From: Adrian Mollenhorst <[email protected]> To: [email protected] Sent: Wed, February 10, 2010 12:57:33 PM Subject: Re: [amibroker] Re: Multiple Systems & Risk Mgmt in one formula Pardon my ignorance, I have never come across CBT. What is it, and where can I learn more? Adrian On Wed, Feb 10, 2010 at 7:04 PM, B S <bs2...@yahoo. com> wrote: >Thanks for that link - looks like there was considerable interest and its been >planned since 2006. Anyone know why it wasn't ultimately implemented? > > > ________________________________ From: "hydrob...@rocketmai l.com" <hydrob...@rocketmai l.com> >To: amibro...@yahoogrou ps.com >Sent: Wed, February 10, 2010 9:07:09 AM >Subject: [amibroker] Re: Multiple Systems & Risk Mgmt in one formula > > >Getting extra data into the CBT can be a challenge. There is a suggestion in >the feedback center here: >http://www.amibroke r.com/feedback/ view_bug. php?bug_id= 598 > > >--- In amibro...@yahoogrou ps.com, B S <bs2...@...> wrote: >> >> Hi- >> >> I asked Marcin a question related to this earlier, but given the >> considerable interest in the past on this board regarding managing multiple >> systems, I'd thought put some further thoughts here. My understanding of >> the conclusion reached during the last round of discussions was that each >> individual should use low-level CBT to accomplish their multiple systems >> management goals. So I've done that, but in the end its of no practical use >> because of the incredible number of static arrays that were required to do >> it - it 'works' on small samples/tests but the memory demands are too great >> for things that I'd actually use it for. As my objectives were rather >> simple, I imagine that others are still wrestling with similar issues. >> >> As an example, part of my plan was to limit the % of equity that was >> employed by any one system at a given time. Therefore, while in the >> backtester I needed to know which system or systems generated the signal. >> So I started by creating a static array that i could later access in the >> CBT which contained flags (1,2,4,etc.) indicating which system or systems it >> came from. However, because of the memory issues, I decided to stuff these >> flags into the positionsize property and just determine the actual size >> later while looping through CBT. That allowed me to determine which systems >> signals were coming from, and then choose which model to allocate the trade >> to (in the event of multiple simultaneous signals), but I still needed to >> get the correct entry price. There could be as many entry prices as I have >> systems, and since I don't know which I'll be using until I get to the >> backtester, I needed to store all of them - another static >> array. This process continued like this and then it occurred to me that >> just about all of these issues would go away if I could just attach the >> information I needed to the entry signal object. So for example, the user >> could set PositionSize1, PositionSize2, PositionScore1, PositionScore2, >> BuyPrice1, BuyPrice2, and so on...or perhaps just dummy variables... Dummy1, >> Dummy2, etc.. I'm sure there's a memory cost to doing this, but it can't >> be anything like storing all these static arrays (is this correct? i really >> have no idea what i'm talking about). Also, I'm sure just making these >> additional property slots available will come at some performance cost, but >> perhaps adding them could be an option in settings. >> >> For all I know, editing the number of properties that can be stored in a >> signal object is already possible - is it? If not, do others think this >> would be useful? Is there a better way of achieving the types of things >> that I'm trying to do? >> >> Appreciate any dialogue whatsoever on this - have spent an embarassing >> amount of time on it without much to show for it. >> > > >
