Re: [amibroker] Re: Multiple Systems & Risk Mgmt in one formula, AmiBroker Email List Archive

2010/3/3 Mike <sfclimbers@xxxxxxxxx>

It's been a while since I looked at this, so do your own testing. But, try something like this:

gain = bo.Equity - bo.Cash + bo.MarginLoan; // Unrealized gain from holdings

buyingPower = (bo.Cash + gain) * 2; // Half equity : half margin.

Mike

--- In amibroker@xxxxxxxxxxxxxxx, Ilhan Ketrez <ketrezilhan@xxx> wrote:
>

> 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 <tomfid@xxx>

>
> >
> >
> > 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 amibroker@xxxxxxxxxxxxxxx <amibroker%40yahoogroups.com>, Ilhan

> > Ketrez <ketrezilhan@> 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 <bs2167@>
> >
> > >
> > > >
> > > >
> > > > 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 <ketrezilhan@>
> > > > *To:* amibroker@xxxxxxxxxxxxxxx <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 <bs2167@xxxxxx com <bs2167@>>
> >
> > > >
> > > >>
> > > >>
> > > >> 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.
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>