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: "[email protected]" <[email protected]> To: [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 --- 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. >
