I can only hope TJ is busy implementing other features with even greater level of interest.
--- In [email protected], B S <bs2...@...> 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...@..." <hydrob...@...> > 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 <bs2167@> 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. > > >
