Right, I know what the acronym means now. Thanks. Adrian
On Wed, Feb 10, 2010 at 8:43 PM, B S <[email protected]> wrote: > > > 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<[email protected]> > > 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 <[email protected]>" >> <hydrob...@rocketmai >> l.com <[email protected]>> >> *To:* amibro...@yahoogrou ps.com <[email protected]> >> >> *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<http://www.amibroker.com/feedback/view_bug.php?bug_id=598> >> >> >> --- In amibro...@yahoogrou ps.com <amibroker%40yahoogroups.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. >> > >> >> >> > > >
