Hi,
Yes, it would appear that you are correct. The default backtester does
not appear to make the position gains available for additional
purchases.
I ran the following test from 1/1/2009 - 12/31/2009 on a watchlist
containing IBM and ORCL. The expectation is that the profits from the
IBM position would be available to enter an ORCL position. However, the
detailed backtester message says that there was insufficient funds.
SetOption("InitialEquity", 85);SetOption("AllowPositionShrinking",
true);SetTradeDelays(0, 0, 0, 0);SetPositionSize(2, spsShares);
dates = DateNum();firstBuyDate = ((2009 - 1900) * 10000) + (100 * 1) +
2;secondBuyDate = ((2009 - 1900) * 10000) + (100 * 12) + 30;
Buy =(Name() == "IBM" AND dates == firstBuyDate) OR(Name() == "ORCL" AND
dates == secondBuyDate);BuyPrice = Open;
Sell = 0;
Seems like it's worth a follow up to AmiBroker support.
Mike
--- In [email protected], Ilhan Ketrez <ketrezil...@...> wrote:
>
> Let me correct my previous e-mail first (corrections are in red):
>
> 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 = (Entry Bar)Equity - total(margindeposit*shares) // Stays
> constant as long as the positions are maintained
> - 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)
>
> ---
> Mike
>
> Let me give you an extreme example:
> Please assume that you enter some positions at a bar and you have $50
cash
> left. All the positions are profitable and you have total(position
P&L) of
> $50,000. Your "buyingPower" variable increases to $50,050.
Backtester's
> buying power stays as $50. It cannot open a position as long as it
doesn't
> have cash.
>
> I wonder your additional comments.
>
> Thank you.
> Ilhan Ketrez
>
> 2010/3/3 Mike sfclimb...@...
>
> >
> >
> > 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 [email protected] <amibroker%40yahoogroups.com>,
Ilhan
> > Ketrez ketrezilhan@ 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@
> >
> > >
> > > >
> > > >
> > > > 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><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:* [email protected]
<amibroker%40yahoogroups.com><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 <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.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
