[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [amibroker] Re: Multiple Systems & Risk Mgmt in one formula


  • Date: Fri, 19 Mar 2010 22:58:26 +0200
  • From: Ilhan Ketrez <ketrezilhan@xxxxxxxxx>
  • Subject: Re: [amibroker] Re: Multiple Systems & Risk Mgmt in one formula

PureBytes Links

Trading Reference Links



Thank you for your efforts and support, Mike.

Amibroker states that due to the ambiguity & variance in initial margin deposits and maintenance margin deposits,
they prefer to include P&L in the position value variable and exclude it from Cash.

Shortly, Amibroker support does not support this idea as you support. Perhaps they may support with your support :)

Ilhan


2010/3/16 Mike <sfclimbers@xxxxxxxxx>
 

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 amibroker@xxxxxxxxxxxxxxx, Ilhan Ketrez <ketrezilhan@xxx> 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 sfclimbers@xxx

>
> >
> >
> > 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 <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 amibroker@xxxxxxxxxxxxxxx <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:* amibroker@xxxxxxxxxxxxxxx <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 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.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>



__._,_.___


**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.

TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com

TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)

For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/





Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___