Thank you very much. If you need any assistance or confirmation, please just let me know.
2010/3/20 Mike <[email protected]> > > > Ilhan, > > Thanks for the follow through. > > I'll have to give this one some thought. I do have a strategy where at > times, albeit briefly, I am fully leveraged and use profits to take on more > positions. > > When I get a little time, I will have to look into this further. I'll let > you know what I come up with. > > > Mike > > --- In [email protected] <amibroker%40yahoogroups.com>, Ilhan > Ketrez <ketrezil...@...> wrote: > > > > 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 <sfclimb...@...> > > > > > > > > > > > > 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] <amibroker%40yahoogroups.com>, Ilhan > Ketrez <ketrezilhan@> 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@ > > > > > > > > > > > > > > > > > > > > > > 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><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 > > > ><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 > > > ><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. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
