Re: [amibroker] Re: Inline Backtester Metrics, AmiBroker Email List Archive

Why reinvent the wheel indeed...

I am a case in point. I have reinvented many wheels. I usually do it out of ignorance. I see a need and start inventing solutions. If I had known and understood the solutions already available before I started, I would not likely have worked on my own solutions which took a lot of time and energy (and sometimes money). The interesting thing is that I have some patents to my name --and also unfortunately some inventions buried by corporations for business reasons to keep them off the market.

I reinvented the wheel and in the process found another way of doing it better by approaching the problems from a different angle --unprejudiced by prior solutions. This is how breakthrough are made -- not by just using or slowly making incremental improvements to existing solutions.

I should not have to tell you this, because you are obviously an inventive sort yourself.

I say if Brian wants to look at things from another angle, encourage him and help him out. Best case we all benefit. Worst case Brian learns a lot.

BTW, I wrote my own back tester in AFL that is quite simple for my simple minded one symbol day trading setup. It does not do any more than I need for this task, but I understand every bit of how it works and can play with different ideas in its guts to test various ideas. One advantage I have with it is since it is always running in indicator mode, I get a continuous read of the last n days results. If I accidentally change or forget to put a parameter back after an experiment, I know it right away before I make a bad trade because the RT BT results will not look right.

I also took a modular approach and can have 4 independent BT systems running at the same time, with the statistics module combining the results of all 4 at the end and generating the trade calls. I don't think I would have thought of that if I had not made my own back tester module.

Best regards,

Dennis

On Aug 1, 2008, at 10:51 AM, Fred Tonetti wrote:

I don’t know what a “GF” is but portfolio trading is NOT the product or sum of trading individual securities as there are a number of other complexities involved.

It’s not a matter of what can or can not be done …

I never suggested it could not be done …

What I asked was … Why reinvent the wheel … The piece you aren’t seeing is that in order to do the same sort of “accounting” that AB does internally in order to come up with an equity curve and / or trade list so that you can calculate whatever performance metrics you want you’ll in essence have to write the same routines in AFL and while AFL is nice and fast it is not C. So … In regards to how many lines of code we might be running when we click the backtest button I think the proper response is … why should we care ? … Whether it’s 2 or 2 million the real question is how long does it take and could we perform the same functions in AFL as quickly AND as accurately. To this I’m sure the answer is that we can’t and so … If you are looking for solutions that are not particularly “elegant” then whatever you do to keep from hitting the backtest button manually or logically in AFL will put you well on the way there …

I went way down this road with “Portfolio Trader” which was a very large ( 20k+ lines ) AFL designed to do portfolio trading prior to those features being available directly from AB … It was great at the time and may have provided some direction as to what was ultimately implemented in AB even though some features never made it … But as soon as AB had most of the capabilities I tossed it in the circular bin even though there were some who wanted me to continue to support it because frankly I have better things to do then write and support stuff that better belongs where it is now and there’s no way I could write it to be as fast as it will be as a feature / function of AB.

The bulk of the code surrounded the necessary bean counting functions to get the equity curve and trade list correct and was a royal PITA to do from AFL … and this was prior to having the ability to scale in/out etc.

From: amibroker@xxxxxxxxxxxxxxx [mailto:amibroker@xxxxxxxxxxxxxxx] On Behalf Of brian_z111
Sent: Friday, August 01, 2008 10:24 AM
To: amibroker@xxxxxxxxxxxxxxx
Subject: [amibroker] Re: Inline Backtester Metrics

Fred,

A couple more.

For multiple securities the Portfolio GF is the product of the
individual symbol GF's - it is like a matrix that adds up in both the
vertical and horizontal directions, so I am good for Portfolio Eq
(that was the missing piece from our first round of discussions).

I haven't worked through all of the implications of that, especially
for the other metrics.

Don't you like that idea for Portfolio Eq?

Re complexity of code:

Not having a go at you, or Tomasz, but when I push the backtester
button how many lines of code do you think 'we' are running then?

So, it is OK for Tomasz to do it where we can't see it but you don't
like it if I expose the innards?

Also this idea that it can't be done!

How did Tomasz do it?

Does he ship Tinkerbell dust with his copies of AB?

AB can't do more than start with the buy/sell price and bars in/bars
out can it? I am trying to think of some other possible required raw
inputs for a BT but I can't (outside of MM which I am not doing yet).

brian_z

--- In amibroker@xxxxxxxxxps.com, "brian_z111" <brian_z111@...> wrote:
>
> > Approaches like this might be sufficient for extremely simple
> systems
> > trading single securities in or out . no scaling . no position
> sizing . no
> > multiple securities . no position scoring .
>
> I am not sure what Herman & Al are up to (don't expect them to tell
> me all OR that they even have fixed needs).
>
> It might do a job for them.
>
> I am using a modular approach, and keeping it basic, because user
> needs could take it in a lot of directions so anyone interested
will
> probably have to add their own bells and whistles, unless we touch
> somewhere.
>
> I am really doing it for myself though and I wanted to start with
the
> most basic scenario, then build on it from there, so I have a
stepped
> degree of difficulty.
>
> I am not interested in scaling (at least I wasn't until Jan said he
> uses it), Psize or Pscore (or open position equity which you didn't
> mention) at the moment.
>
> I wasn't out to solve for multiple securities but I think I have
that
> covered anyway (Herman wants that though).
>
> I am interested in all signals so I am starting to play with that -
> not sure what I am letting myself in for there.
>
> > The problem is as you add any of these complexities the AFL to
> >support them
> > becomes needlessly complex .
>
> Yes, I might not go much further.
>
> A little bit of experience of the complexities of programming won't
> hurt me.
>
> I am actually comfortable with the metrics like W/L, PayOff Ratio
and
> I can get them pretty easy for the trade series I have already.
>
> Plus I said before that we couldn't get the SD of an inline trade
> series but now that I am into it I think I see a way that I can.
>
> > Again . Why reinvent the wheel . This is why there is a
backtester .
>
> Core reasons:
>
> I have it in my head that there will be a time penalty if I run the
> BT.
>
> It doesn't seem such an elegant solution to me.
>
> I just like it more (not really a reason since we can't explain our
> likes and dislikes.
>
>
> Indirect reasons (not in order):
>
> - it might help Herman and he does a lot for others and also has
been
> good with me
> - I have a stubborn side and once I get my teeth into something?
> - I am not so motivated to write code at the moment but I seem to
be
> enjoying this one
> - my RCE 'theorom' aren't going to be a lot more useful to me if
> I 'write them up' but it has a certan elegance so it is worthy of
> completion
> - my RCE theories aren't complete so this helps me sort it in my
head
> (I have to take it apart and consider each step logically - if I
can
> code it I must understand it)
> - we have different personal styles/trading styles. I like to get a
> lot of chart time and trade in the charts without props (sometimes
I
> can't use the optimum broker available, which is IB for US
> foreigners, for various reasons, so it is good for me to be able to
> trade in a Java platform without props. For that reason I need to
> comfortable at working in line (a Java platform with no
customisation
> is the real trading world for me).
> - it is helping me understand the backtester more
> - I am playing around with the idea of an inline MM indicator and I
> might try to throw one in at the end of the code
>
> No guarantee I will go beyond trying concurrent multiple trades
> anyway.
>
> > for (i = 1; i < BarCount; i++)
> > {
> > EF[i] = EF[i-1] * TradeSeries[i];
> > }
> >
> > This can be done without a loop using logs, addition and
antilogs .
>
> That's great.
> Thanks.
> I really wanted not to have to use a loop.
> I wish I had thought of that.
>
> I have used log before - funny how sometimes you can't connect the
> dots until someone shows you how (experience).
>
> brian_z
>
> --- In amibroker@xxxxxxxxxps.com, Fred Tonetti <ftonetti@> wrote:
> >
> > Approaches like this might be sufficient for extremely simple
> systems
> > trading single securities in or out . no scaling . no position
> sizing . no
> > multiple securities . no position scoring .
> >
> >
> >
> > The problem is as you add any of these complexities the AFL to
> support them
> > becomes needlessly complex .
> >
> >
> >
> > Again . Why reinvent the wheel . This is why there is a
backtester .
> >
> >
> >
> > . And as far as .
> >
> >
> >
> > for (i = 1; i < BarCount; i++)
> > {
> > EF[i] = EF[i-1] * TradeSeries[i];
> > }
> >
> >
> >
> > This can be done without a loop using logs, addition and
antilogs .
> >
> >
> >
> > _____
> >
> > From: amibroker@xxxxxxxxxps.com
[mailto:amibroker@xxxxxxxxxps.com]
> On Behalf
> > Of brian_z111
> > Sent: Friday, August 01, 2008 6:49 AM
> > To: amibroker@xxxxxxxxxps.com
> > Subject: [amibroker] Re: Inline Backtester Metrics
> >
> >
> >
> > Herman and Al,
> >
> > I took the scissors to my first effort.
> >
> > It isn't an inline backtester, rather an inline RootCauseMetrics
> > indicator (possibly it could be used for calculating the common
> > Performance Metrics 'on the fly', including with lookback
periods).
> >
> > This is the basic starting module.
> >
> > It should be possible to modify it to allow for concurrent
signals,
> > open trade interest, although it gets a bit harder from here for
me
> > (maybe not for others).
> >
> > I have checked it over a few charts and so far it stands up O.K
> > I haven't used in the line of fire though.
> >
> > Any potential in it for you guys?
> >
> > FTR
> >
> > This is a continuation of discussion at topic:
> >
> > "How To Save Metrics In Composite For Indidual BT's"
> >
> > A little background discussion about the idea behind the code is
at
> >
> > message # 127383 and # 127420 in the above thread.
> >
> > //P_InLineMetrics
> >
> > //Monday is used as the example because it is an unambiguous Buy
> > //Typically most markets have Mon or Fri public holidays so it
> allows
> > for checking code response to duplicate buys and sells (signal
> errors)
> > //BarIndex() is added as a buy condition to workaround the
> > propogating of {empty} values that can arise in the first few bars
> > //A latch is used so that only one trade can be entered at a time
> and
> > every Sell must have a corresponding Buy
> > //Plots the trade series, as GrowthFactor, which is equivalent to
%
> > //No trades are accounted for and recorded as GF 1
> > //The code doesn't identify break even trades i.e. GF == 1 but it
> can
> > be modified to do so
> > //since commissions aren't considered the Eq outcome for break
even
> > trades is correct
> > //the progressive product of the GF is equivalent to the Equity
> Curve
> > for a fixed capital investment
> > //if the intitial Equity is 1 the EQ is the standardised Equity
> Factor
> > //Equity == Initial Equity * EF
> > //the product of individual GF's, sumbol by symbol, is the
> Portfolio
> > Growth Factor the progessive product of which produces the
> Portfolio
> > Equity Factor
> > //same bar entry/exits are not allowed but the code can be
modified
> > for that if required
> >
> > //PART IA TRADE SERIES MODULE (CLOSED TRADES - ONLY ONE TRADE PER
> > SYMBOL OPEN AT A TIME)
> >
> > M = DayOfWeek() == 1;
> > F = DayOfWeek() == 5;
> > BI = BarIndex()== 0;
> >
> > B = M;//Buy on Monday
> > S = F OR BI;//first bar set to sell and then sell on Friday's
> > thereafter
> >
> > B = Flip(B,S);//latches the Buy signal to prevent concurrent buys
> >
> > BP = SP = C;//BuyPrice, SellPrice
> >
> > //Plot(B,"Buy",5,1);//FFP - fault finding plot used when writing
> the
> > code
> > //Plot(S,"Sell",2,1);//FFP
> >
> > //Plot(BP,"BuyPrice",5,1);//FFP
> > //Plot(SP,"SellPrice",2,1);//FFP
> >
> > TradeSeries = IIf(S ==1 AND Ref(B,-1) == 1,SP/ValueWhen(B == 1
AND
> Ref
> > (B,-1) == 0, BP,1),1);//
> >
> > Plot(TradeSeries,"TradeSeries",1,1);//as GrowthFactor
> >
> > EF = 1;//initialises EquityFactor to 1
> >
> > for (i = 1; i < BarCount; i++)
> > {
> > EF[i] = EF[i-1] * TradeSeries[i];
> > }
> >
> > Plot(EF,"EquityFactor",5,1);
> >
> > --- In amibroker@xxxxxxxxx <mailto:amibroker%40yahoogroups.com>
> ps.com,
> > "brian_z111" <brian_z111@> wrote:
> > >
> > > Herman,
> > >
> > > IBM PartI
> > >
> > > I am not sure if this is along the lines that you are
> investigating.
> > > It might be a starting point.
> > > Sophisticated functions can be built from the concept.
> > >
> > > Example of using single symbol equity function to back
calculate
> > the
> > > trade series.
> > >
> > > I used buy Tues(C) and sell Thurs(C) with one month of data to
> test
> > > the code as I went along (this gave me unambiguous signals with
> > only
> > > one signal at a time - I believe you can use an eq flag to dump
> > dual
> > > signals for real life use).
> > >
> > > Note: some weeks don't have Mons or Fris so I wanted to avoid
no
> > > signals, caused by short weeks, during testing
> > >
> > > I used barindex() > 4 to cut out the first week in the month so
> > that
> > > I started with no signals for a few bars before the first buy.
> > >
> > > I left the plot code in there but commented out (I plotted each
> > line
> > > to test the veracity of the code).
> > >
> > > Note that when the trade series is used to recreate the eq
curve
> > (as
> > > a cross check) it only matches on the exit bars for each trade.
> > > I tried it on 10 years of Yahoo data and the final eqs matched
to
> 2
> > > decimal places (rounded off).
> > >
> > > //P_InLineEquity
> > > //code to reverse engineer the trade series from the equity
curve
> > > //it is reversed at the end to check the accuracy of the method
> > >
> > > InitialEq = 10000;//input required
> > >
> > > SetOption("InitialEquity", InitialEq );
> > >
> > > Buy = BarIndex() > 4 AND DayOfWeek() == 2;//use your own
> > > Sell = BarIndex() > 4 AND DayOfWeek() == 4;//use your own
> > >
> > > BuyPrice = C;//use your own
> > > SellPrice = C;//use your own
> > >
> > > Plot(Equity(),"Equity",5,1);
> > >
> > > Entry = IIf(Equity() == Ref(Equity(),-1) AND Equity() != Ref
> (Equity
> > > (),1),1,0);
> > >
> > > //Plot(Entry,"Entry",1,1);
> > >
> > > Exit = IIf(Equity() != Ref(Equity(),-1) AND Equity() == Ref
(Equity
> > > (),1),1,0);
> > >
> > > //Plot(Exit,"Exit",2,1);
> > >
> > > TradeSeries = IIf(Exit ==1,ValueWhen(Exit == 1,
> > SellPrice,1)/ValueWhen
> > > (Entry == 1, BuyPrice,1),1);
> > >
> > > //Plot(TradeSeries,"TradeSeries",1,1);
> > >
> > > GF = 1;//GrowthFactor
> > >
> > > for (i = 1; i < BarCount; i++)
> > > {
> > > GF[i] = GF[i-1] * TradeSeries[i];
> > > }
> > >
> > > //codesters might be able to make the above loop
better/prettier?
> > > //Plot(GF,"GrowthFactor",5,1);
> > >
> > >
> > > Plot(InitialEq * GF,"CalculatedEquity",1,1);
> > >
> >
> >
> >
> >
> > _____
> >
> > I am using the free version of SPAMfighter for private users.
> > It has removed 516 spam emails to date.
> > Paying users do not have this message in their emails.
> > Try SPAMfighter <http://www.spamfighter.com/len> for free now!
> >
>

I am using the free version of SPAMfighter for private users.
It has removed 516 spam emails to date.
Paying users do not have this message in their emails.
Try SPAMfighter for free now!