Getting extra data into the CBT can be a challenge. There is a suggestion in the feedback center here: http://www.amibroker.com/feedback/view_bug.php?bug_id=598
--- In [email protected], 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. >
