|
PureBytes Links
Trading Reference Links
|
Apologies for the spelling and grammar ... I don't have the ergs to
write drafts, or make corrections, anymore.
A simple example to help explain what I am trying to share with the
community:
- day trading
- enter at or near open
- exit at or near close
- say, 5 min bars
(one trade per day so there is no argument about overlapping trade
closure, for now)
- on day 1,2 and 3 we get only one signal and enter/exit one trade
per day
- day 4 we get 3 signals at the same time (on the same bar)
- thereafter we get one signal a day, say for days 5-10 inclusive)
(this is a small datasample, and, although in real life datasets are
non-stationary, for the sake of the exercise we can pretend that the
pattern is repetitive, although we won't be referencing the future
anyway)
- imagine the trade series as a matrix
we have something like
a b c x d e f g h i
y
z
- if we perform 'real life' analysis we walk through the trades
series (sorted by time)
- if we make an oo number of random walks we will achieve a result
where we have lots of series like this (typical) ... we never die we
just keep on trading ... the system is that good we have no need for
another ;-)
(this assumes that we place equal value on selection x,y or z)
a b c X d e f g h i
a b c Y d e f g h i
a b c Z d e f g h i
The end result will be the mean of the above three possibilities
because as we approach infinity they will all have been selected an
equal number of times.
Note that the mean outcome is that you have 1/30 prob of selecting x
y or z and 3/30 prob of any other selection.
(IMO opinion the Geometric Mean is the best metric to use to compare
systems, so the GM of this matrix is one dimension of the systems
profile).
However, X,Y and Z are only unique in time but not necessarily in
value (%) because they are part of the trade sample space, which is
bounded by our system rules and the characteristics of the underlying
market (data sample space).
The probability of picking the trade value X,Y and Z would be the
same as for a -> i if they all have the same % value i.e. 1 = =
certainty.... if that is the case then you must have your money in a
fixed interest deposit.
(it is the value of the trades, and the frequency of their
occurrence, that determines equity outcomes).
So a random walk, through the total trade sample space, is the
correct procedure to use, because as we move towards OO our trade
selections tend to 'mirror' the underlying distribution with
increasing accuracy.
Unless we want to analyse the trade sample space, section by section,
the frequency distribution of the total trades is the determiner.
Sorry but I can't do anything about non-stationarity .. you will have
to talk to GOD about that one!
For case example 2:
We only have one possibility but we have it three times :-)
a b c x d e f g h i
(X is selected over Y or Z based on an addional criterian (rule) ==
signal ranking
We either select
a b c X d e f g h i
OR
a b c Y d e f g h i
OR
a b c Z d e f g h i
Now we have three, and only three, sub-systems, each with their own
GM, that we can use for relative performance comparison.
Technically we have three different systems and we only need to
select the best of the three and go with that ... the additional rule
would then cease to be an elective rule ... the bad systems would be
dropped and no longer used (unless there are no top system trades
available).
Once again we can see that it is the distribution of the trade values
(%) hiding under X, Y and Z, that is the determining factor
(probability of getting that value).
We could just as easily make that selection by running three separate
BT's for each of the (sub) systems.
The only benefit of saving the trade series as matrices is that we
can visualise relationships, between subsets, and then apply them
with hindsight i.e. we can brainstorm to create new systems, based on
our intitial test successes or failures, without having to re-run all
of the tests.
Whether we do that by elegant or brute means is beside the point.
(out of a sense of pride, and curiousity, I continue to pursue
elegant mathematical resolutions).
--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> > Testing a system like this using a
> > random positionscore is a good indication if it can be made into
a
> > system that can be used in the practice.
>
> I think a lot of people, in the trading community, are a bit light
on
> when it comes to this topic.
>
> It is incredible how, collectively, 'we' have made hard work out of
a
> subject that is relatively simple, if we strip away the stuff that
is
> blocking our view.
>
> The fact that Money Management and Portfolio Optimization was born
in
> Academia, and is still nourished there, doesn't help (are we
> academics or traders?)
>
> It is typical, that we start off by use something that we have,
> anything, and also allow ourselves to be influenced by community
> norms (how else can we get started) and then we get stuck in that
rut.
>
>
> Anyone care for a second opinion?
>
> It would be easier to compare notes if we had something to show it
on
> (if I had a BT that produces the trade series,as an indexed list, I
> could then go on to show how to use it for MM and PO).
>
> Why don't I just go ahead and do that myself?
>
> Because I am an ideas man, not a CEO or a 'Head of Computing'.
>
> All of our signals, including competing signals i.e. signals that
> occur at the time we have insufficent funds to take them (your
> trading model, not mine) go on to become a trade, once they are
> nominally closed. The competing signals just become a mixed set of
> closed trades, some of which were selected, in 'real' trading, and
> the rest, that weren't.
>
> The trades are best measured in % terms, as GrowthFactor i.e. 3%
gain
> = = 1.03 and 3% loss == 0.97 (this standardisation allows for
easier
> and consistent processing and further analysis down the line).
>
> The profile of the system, any system, is the list of trades it
> produces i.e. the trade sample set.
>
> The distribution of the trades is the system profile e.g. if the
> trades have a uniform distribution AND we randomly select trades
from
> the 'bin', with replacement, AND we continue towards infinity OO ,
we
> will eventually select all samples the same number of times, +- an
> insignificant difference.
>
> In this case, analysing the complete trade set (all possible
trades),
> is a short cut on the path to massive random sampling.
>
> If the distribution of the trades is non-uniform, then the equity
> outcomes is a derivative of that distribution, and mathematical
> derivation, or massive random sampling, is the only way to conduct
> that analysis.
>
> Therefore, sampling all trades, either in total OR as subsets, for
> sample space analysis/signal ranking etc, is the correct approach,
as
> per my comments in the topic TRADE SERIES MATRICES USING C++
>
> The trade distribution isn't necessarily a Bell Curve, and for that
> reason, MonteCarloSimulation, or similar brute force methods is one
> valid, and effective, way to go about (Binomial Simulation, a
method
> that I am playing around with, is another approach that is
similar ..
> as before I will post on that subject ASAP but I am getting busier
> and busier elsewhere).
>
> The early method, used by RalphVince, where he considered the total
> set of closed trades and biased the 'resolution' to the max loss
was
> an attempt, on his part, to analyse the system profile as defined
by
> it's distribution i.e. optimal F
>
> In his later books he attempted to rectify the weaknesses of this
> method and include the worst case scenario in his estimates i.e. he
> tried to make allowance, in his calculations, for the worst trade
> that we are still to have.
>
> Of course, this is an impossible mission, since we can never be
> certain about the future, only significantly optimistic.
>
> It is however, still worthwhile to make the probability estimation,
> for our own peace of mind.
>
> As promised before:
>
> when the (BT) vehicle is ready the Money Manager will appear!
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Mike" <sfclimbers@> wrote:
> >
> > Ha ha.
> >
> > Just goes to show how people can get tunnel vision sometimes.
Since
> I
> > do a lot of custom backtester code, I immediately suggested
> filtering
> > at that level.
> >
> > But, your suggestion of a random value for PositionScore directly
> > would be far easier and less prone to coding error.
> >
> > Mike
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "Edward Pottasch" <empottasch@>
> > wrote:
> > >
> > > you are right on this Mike. Testing a system like this using a
> > random positionscore is a good indication if it can be made into
a
> > system that can be used in the practice. Andy has an idea that is
> > tough to execute but not impossible in my opinion,
> > >
> > > regards, Ed
> > >
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Mike
> > > To: amibroker@xxxxxxxxxxxxxxx
> > > Sent: Thursday, January 29, 2009 8:37 PM
> > > Subject: [amibroker] Re: Sell and Buy on different days
> > >
> > >
> > > Andy,
> > >
> > > Use caution when backtesting EOD strategies where there are
> more
> > > signals than there are funds or positions to be filled;
> > >
> > > If your strategy is to buy OCA, what logic are you putting in
> > place to
> > > determine which symbol to buy when multiple symbols hit your
> limit
> > > order on the same bar?
> > >
> > > Since you are using EOD data, you have no idea which symbol
> would
> > have
> > > hit the limit order first. You only know that x of y symbols
> hit
> > the
> > > limit order on that day.
> > >
> > > AmiBroker will just select the first in the list
> (alphabetically?
> > ). As
> > > such, your backtest results will be heavily biased in favor
of
> > that
> > > ordering and will not reflect live trading results.
> > >
> > > Generally, PositionScore can be used to influence ordering.
> But,
> > an
> > > OCA approach by definition does not follow PositionScore.
> > >
> > > So, you might want to modify your custom backtester code to
> > randomly
> > > select from the available signals and set the remaining ones
to
> > > PosSize 0 in order to override the default prioritization.
Then
> > run
> > > your backtest many times and take the average of the results
as
> a
> > best
> > > guess estimate (i.e. Monte Carlo Permutations)
> > >
> > > Mike
> > >
> > > --- In amibroker@xxxxxxxxxxxxxxx, Andrew Senft <senft@> wrote:
> > > >
> > > > Hey Ed,
> > > >
> > > > Thank you so much for the code on the Amibroker Yahoo group
> > board!
> > > It
> > > > seems to be working from what I've seen so far. I'm doing
an
> > > > optimization on that particular code (your first code)
right
> > now.
> > > >
> > > > The second code (the one from your email) didn't work. That
> is,
> > > there
> > > > were sales of one stock and buy of another stock on the
same
> > day.
> > > Not
> > > > sure what your code was doing but it gave a lot bigger
> profits
> > using
> > > the
> > > > backtester. Could you comment on this please?
> > > >
> > > > Mind you that this is my first attempt to writing code for
> any
> > stock
> > > > type software. I'm still using the 30 day free trial of the
> > > Amibroker
> > > > software but I think that I'm getting closer as I'm
chugging
> > along.
> > > >
> > > > My agenda is to use this on a basket of ETF's. Perhaps 10
to
> 20
> > > or
> > > > so. Not sure how many I need since the 30 day trail
backtests
> up
> > > to a
> > > > basket of 5 stocks. My idea is to place the possible stock
> > trades
> > > > using the whole basket of ETF stocks at night for the next
> > trading
> > > > session. I have an IB account so I figure I could use an
OCA
> > limit
> > > > order. Basically whenever a trade gets hit first (meets the
> > limit
> > > price
> > > > level), it trades. The other possible trades all get
canceled
> > right
> > > > away. So one trade actually goes through for the day.
> > > >
> > > > BTW, I like ETF's because the drawdowns are not as
scary....
> > okay,
> > > > usually not as scary. Ha! I've been backtesting with:
> > > >
> > > > QQQQ, DIA, SPY, MDY, IWM
> > > >
> > > > Thank you again!
> > > >
> > > > Andy
> > > >
> > > > Edward Pottasch wrote:
> > > > >
> > > > > Andy,
> > > > >
> > > > > I have sent an alternative solution to your private
Email.
> Let
> > me
> > > know
> > > > > if you received it.
> > > > >
> > > > > Ed
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > *From:* Andy <mailto:senft@>
> > > > > *To:* amibroker@xxxxxxxxxxxxxxx
> > > <mailto:amibroker@xxxxxxxxxxxxxxx>
> > > > > *Sent:* Thursday, January 29, 2009 12:40 PM
> > > > > *Subject:* [amibroker] Re: Sell and Buy on different days
> > > > >
> > > > > This is got to be a very simple task but unfortunately
> > > AmiBroker told
> > > > > me that I would have to write Backtester Interface code
for
> > > this. I'm
> > > > > sure this has been done a million times. Anyone have
sample
> > > code?
> > > > > I'm using EOD data to trade one stock at a time from a
> basket
> > > of
> > > > > stocks. The problem is that a selling of a stock can
occur
> on
> > > the
> > > > > same day as a buy of *another* stock. Of course the
problem
> is
> > > that
> > > > > the sell trade can occur after the buy trade.
> > > > >
> > > > > --- In amibroker@xxxxxxxxxxxxxxx
> > > > > <mailto:amibroker%40yahoogroups.com>, "Andy" <senft@>
wrote:
> > > > > >
> > > > > > How do I fix the below code so it doesn't buy a
different
> > > stock on a
> > > > > > sell day?
> > > > > >
> > > > > > --------------------------------------------------------
> > > > > > // Backtester Options
> > > > > > SetOption("MaxOpenPositions", 1 );
> > > > > > SetOption("AllowSameBarExit", False);
> > > > > >
> > > > > > // Optimization numbers
> > > > > > BuyPeriod = Optimize("BuyPeriod",16,10,20,2);
> > > > > > BuyFactor = Optimize("BuyFactor",1.2,0.5,1.5,.1);
> > > > > > SellPeriod = Optimize("SellPeriod",20,10,20,2);
> > > > > > SellFactor = Optimize("SellFactor",0.8,0.5,1.5,.1);
> > > > > >
> > > > > > // ATR formulas
> > > > > > TodaysBuyTarget = High - BuyFactor * ATR(BuyPeriod);
> > > > > > YesterdaysBuyTarget = Ref(High,-1) - BuyFactor *
> > > > > Ref(ATR(BuyPeriod),-1);
> > > > > > YesterdaysSellTarget = Ref(Low,-1) + SellFactor *
> > > > > Ref(ATR(SellPeriod),-1);
> > > > > >
> > > > > > // Buy/Sell signals and prices
> > > > > > Buy = YesterdaysBuyTarget > Low;
> > > > > > BuyPrice = IIf(YesterdaysBuyTarget > Open, Open,
> > > > > YesterdaysBuyTarget);
> > > > > > Sell = YesterdaysSellTarget < High;
> > > > > > SellPrice = IIf(YesterdaysSellTarget < Open, Open,
> > > > > YesterdaysSellTarget);
> > > > > > Buy = ExRem(Buy,Sell);
> > > > > > Sell = ExRem(Sell,Buy);
> > > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------
> > > ------
> > > > >
> > > > >
> > > > > No virus found in this incoming message.
> > > > > Checked by AVG - http://www.avg.com
> > > > > Version: 8.0.176 / Virus Database: 270.10.15/1921 -
Release
> > Date:
> > > 1/28/2009 6:37 AM
> > > > >
> > > > >
> > > >
> > >
> >
>
------------------------------------
**** IMPORTANT ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
*********************
TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
*********************
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
*********************************
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|