Hello Thank you for participating. As you mention and as I understand, considering bo is the backtester object;
In Amibroker: - bo.Equity is the bar by bar value of the equity - bo.Equity = bo.Cash + total value of positions //see below for definition - bo.Cash = bo.Equity - total(margindeposit*shares) - Value of position = margindeposit*shares +- position P&L In real life: - Equity is the day by day value of the equity - Equity = Cash + total(margindeposit*shares) +- total(position P&L) - Cash = Equity - total(margindeposit*shares) +- total(position P&L) - value of position - no need to define (at most the initial margindeposit*shares is required to keep the position) Amibroker states that due to the ambiguity & variance in initial margin deposits and maintenance margin deposits, they prefer to include it in the position value variable. However this solution prevents coding margin calls and hence also prevent playing at the limits in terms of position sizing such as opening positions by using profits of open positions. I wonder your additional comments on the subject. Sincerely, Ilhan 2010/2/25 tf28373 <[email protected]> > > > I've thought that it's just required to define the difference between > bo.Equity (which - as I've understood - is current value of our intial > equity and all open positions) and bo.Cash (initial capital minus cost of > opening position that is margin deposit) in order to estimate if trades are > gainers/losers and, thus, current available capital...? Isn't it like that? > > --- In [email protected] <amibroker%40yahoogroups.com>, Ilhan > Ketrez <ketrezil...@...> wrote: > > > > Yes. Simple backtester doesn't know the equity and capital available. > > CBI does know the Equity. > > Even the CBI doesn't know the actual available capital unless we define > and > > calculate ourselves. > > And even if we define and calculate, we still cannot utilize it when we > need > > since we cannot define it as BacktesterObject.Cash. > > BacktesterObject.Cash gives the difference of Equity - entry time (shares > * > > margindeposit). Cash earned/lost by the position stays in the position > and > > doesn't change the BacktesterObject.Cash. > > > > > > 2010/2/10 B S <bs2...@...> > > > > > > > > > > > > Yes, thanks...that's similar logic to what Paul Ho suggested with his > > > multiplex function, but it unfortunately does not address the issue of > > > picking between simultaneous signals from multiple systems based upon > the > > > capital available to each system (unknown until you get to that bar in > the > > > backtest loop). > > > > > > ------------------------------ > > > *From:* Ilhan Ketrez <ketrezil...@...> > > > *To:* [email protected] <amibroker%40yahoogroups.com> > > > > *Sent:* Wed, February 10, 2010 2:18:41 PM > > > *Subject:* Re: [amibroker] Multiple Systems & Risk Mgmt in one formula > > > > > > > > > > > > Setting different ranges of scores and buy-sell prices for different > > > systems by simple IIF function may be a solution, at least lightens the > > > problem I guess. > > > > > > 2010/2/10 B S <bs2...@yahoo. com <bs2...@...>> > > > > > > >> > > >> > > >> 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. > > >> > > >> > > >> > > > > > > > > > > > > > >
