|
PureBytes Links
Trading Reference Links
|
Hello,
I have started thinking about the design for a MatrixBacktester and
uploaded my rough notes, as a word file, to the files section of this
board.
I don't think anything like it is around.
It would be great of someone (anyone) developed the program.
Even better if Tomasz put it in AB.
I don't have any intention to start writing it, at the moment.
I would rather others did it (I don't have the plumbing for world
class maths/code).
If I am still frustrated with the current crop of BT's, in 6 months,
I might start as an R Project to develop it as an open source
collaborative project.
The babblers appendix:
You can access SuperConsciousness, via the subconscious mind (you
have to go down into the basement and throw all the junk out to find
it).
When you are working in the subjective mind (right brain?) you can't
pay 100% attention to the objective mind (left brain) e.g. you don't
see exactly what you are typing.
In the subjective 'world' there is no past or future ;-)
--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx>
wrote:
>
> I didn't want to bother the forum on this topic again, since there
is
> no discussion forthcoming, but I have since found out that
> multidimensional matrices are real and a standard programming
> procedure.
>
>
> As far as I can tell, they are mainly used for solving complex
> problems .... I believe computational time raises exponentially as
> more dimensions are added ... I think they would be overkill for
AFL
> so I am now, more or less, satisfied that cutdown pseudo matrices
> would be fine for the job.
>
> This would amount to little more than a collection of 'callable'
> arrays, per system OR subsystem ... they would comprise a much
> smaller sample space than the data itself, as in most cases they
> would be relatively short vectors .... since array processing would
> still apply I assume that processing could still be very fast once
> they have been created.... so while there is a time penalty
involved
> in their creation there is some time payback to justify the effort
> (the more often the users queries the matrices, to perform sample
> space analysis, the sooner the payback line is crossed).
>
>
>
> My only interest there now is to speed compare languages, and
> programming methods, for managing the 'matrix' arrays.
>
> I believe that in C++ tensors is one method used ... essentially
this
> indexes a single array (a N == 1 multi-dimensional matrix) to
produce
> the sub-matrices.
>
> Since this has a time penalty attached the way to go would be to
> allow users, who don't want to use signal ranking OR sample space
> analysis etc, to toggle off matrix indexing and simply collate the
> database trades as a single time series.
>
> If any laypeople are interested in getting their head around the
> subject here are some starter links (not great ones but they do
> provide some insight into what I am talking about and show how
> simple, and intuitive, the required AFl functions could be):
>
>
> http://en.wikipedia.org/wiki/Matrix_(mathematics)
>
> http://www.absoluteastronomy.com/topics/MATLAB
>
> In both the total trade series OR the subseries, the sequence of
> trades, as per the time of entry, would need to be preserved or
> restored (sort, within the matrices,by entry time) for those who
want
> to replicate the 'real' trading environment.
>
> My questions now are mainly centred around fast ways to rip the
trade
> series (either as a single array or referenced by symbol for matrix
> use).
>
> So far I have three areas to think about:
>
> a) programmatical - AB uses trade lists, which must have a
> computational cost... I assume this is the current optimal
method ...
> looking around to see what other programmers and other languages
are
> capable of ... gains here are likely to be relatively small except
> for the fact that I am getting prompted, by my subconscious, that
> something else is out there or waiting to be discovered.
>
> b) multicore processing - a quantum leap ... no self-respecting
> backtester would be without it
>
> c) follow DLoyers lead into GPU processing to do the ripping (Very
> neat DL ... you might be the one who finally turned me into a
> programmer after Tomasz kickstarted the job).
>
> While on the subject of MCP ... I came across this article ...
> doesn't have anything to do with the current topic but since I have
> previously posted my 'idea' of giving AB a software 'brain' to
manage
> processing load distribution, for MCP machines (particularly
> considering that AB will ecounter a large variety of MC configs) I
> thought I would post it as some sort of vindication ... I always
live
> in hope that I am not nuts afterall ;_)
>
> If you are a mad philospher it always helps to hang out with a
group
> of crazies and then you won't be so conspicuous!
>
> http://www.mc.com/uploadedFiles/MCF-API-Conf-Paper.pdf
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> >
> > > I have been experiencing repeated thougnts about 64 bit
> > >programming,
> > > using tricky methods to store trade data, with minimal memory
> use,
> > > and 3,4, or more, dimensional matrices
> >
> > Does anyone know where I can find something about minimizing
memory
> > use with data handling and/or programming multidimensional
matrices
> > Or are we still waiting for someone to invent them?
> >
> > Where do the crazy programmers hang out and talk about this stuff?
> >
> > Which language is the best for writing a backtester in?
> >
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
wrote:
> > >
> > > IMO backtesters that combine money management, scaling in and
> > signal
> > > ranking in one step are not using the best, or most efficient
> > method.
> > >
> > > On the contrary, this approach can muddy the waters and create
> > > confusion for the user, especially new comers.
> > >
> > > It is well known that if piano students do not start by
learning
> > the
> > > correct, albeit funNOT techniques, they will almost certainly
> never
> > > learn to play at advanced levels.... the end justifies the
means
> > (and
> > > the high attrition rate).
> > >
> > > Collecting all matched buy/sells first is the best approach (as
> > used
> > > by RalphVince and MSA Analyzer) .... sequential or random
testing
> > of
> > > MM, scaling in, trade sample space analysis and ranking etc can
> be
> > > performed, as per user requirements, from the trade matrix,
which
> > > afterall is a constant for any constant set of rules and data.
> > >
> > > For anyone who is thinking of attempting it privately:
> > >
> > > - the system rules i.e. buy/sell/prices/stops etc (not MM
rules)
> > need
> > > to be saved with the trade matrices
> > >
> > > - when a system is reopened from the historical archive the
rules
> > > need to be auto restored to the backtester (exactly as per the
> > > original test)
> > >
> > > - versioning would need to be introduced ... if the user adds
> some
> > > code to the the rules then they need to elect to run it as a
new
> > sub-
> > > version (save the matrix/rules separately) OR as a new test
that
> > > overwrites the archived trade matrix.
> > >
> > > - for optimization a user election would save all matrices and
> > rules
> > > as sub-versions
> > >
> > > - scaling in should be treated as a new and different sub-
> > system ....
> > >
> > > system 1 = conditional on the set of rules A
> > > scaling in = system 1.1 = conditional on A then apply rule B
> > >
> > > .... different combinations of MM rules can then be tested on
> > system
> > > 1 + system 1.1 versus system 1 OR system 1.1. to find where the
> > > optimum returns are.
> > >
> > > - ranking signals is a challenge ... my first thoughts are that
> the
> > > ranking indicator would need to be collected with the trade
> signals
> > > and saved with them.
> > >
> > > The careful reader might have noted that this discussion is an
> > > extension of the topic SYSTEM PERFORMANCE INDICATORS where I
came
> > up
> > > against the (wall) limits imposed by computation and AFL .....
> > > ripping the mimimum data (trades only) required for performance
> > > metrics i.e. core metrics, process only the essential metric
> > > (objective function) and doing it on the fly (cached) for a
> > reasonale
> > > number of symbols is the challenge.
> > >
> > >
> > > Currently obtaining all matched signals (trades) in AFL isn't
the
> > > default and perhaps a little difficult to achieve.
> > >
> > > Finding a fast efficient way to do this is the key to the
> challenge.
> > >
> > > From what I can find out from the docs the AB method is to save
> > > trades in a trade list .... I assume this has a time penalty
> > attached
> > > but in programming alternatives seem few and far between ???
> > >
> > > My interest now is the relative speed OR otherwise of different
> > > langauges/matrix/array processing when ripping the trade series
> > from
> > > the data followed by the subsequent speed when calculating the
> > > metrics (the bias is on getting the trade matrix though).
> > >
> > > I have been experiencing repeated thougnts about 64 bit
> > programming,
> > > using tricky methods to store trade data, with minimal memory
> use,
> > > and 3,4, or more, dimensional matrices ... how crazy is
that ...
> I
> > > don't even own a 64 bit compputer and barely know the first
thing
> > > about computers or programming?
> > >
> > > I don't find AFL a good language to learn programming from (for
> > first
> > > timers like myself) possibly because it has been simplified and
> > also
> > > because it doesn't have an intimate relationship with the
> computer,
> > > being a sort of second order C++.
> > >
> > > For programming research and education I am looking at other
> > > languages and open source projects ... so far R Math is #1 on
my
> > > short list. It only has a small amount of code written for
> trading
> > > but there might be some potential there.
> > >
> > > Plus there is a handful of AB people interested in R and we
have
> > the
> > > plugin (thanks to Patrick).
> > > At least it gives me a chance to learn something about wider
> > > programming techniques, including lists and matrices, (AFL is
> > > reasonably transparent and documented but R language is much
> richer
> > > and completely transparent and owned by the user which makes
for
> a
> > > better learning environment).
> > >
> > > What I find out there I could apply to AB via a plugin but that
> > would
> > > mean I would end up only using AB as a data downloader and
> charting
> > > package (more craziness)!
> > >
> > > I am not likely to publish anything for a while, if at all,
> unless
> > I
> > > get real excited about it.... one can always rely on the 'good
ol
> > > workaround'!
> > >
> > > Lucky for AB I don't pay a programmer to write the AB plugin,
> > > commercialise it and copyright the code ;-)
> > >
> > >
> > > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
> wrote:
> > > >
> > > > I forgot to mention that another prime objective, of the
> overall
> > > > method, is to make efficient use of our precious data.
> > > >
> > > > All trades are recording in Phase I, so that our elected N
> value
> > (a
> > > > statistically valid sample)is approached using a minimum
amount
> > of
> > > > data...... for WF analysis N could be the cut off point for
the
> > > > sample space used.
> > > >
> > > > BTW this one is for the programmers, and serious dudes, who
for
> > the
> > > > most part, tolerate my biblings and scribblings (hope you
like
> it
> > > > Fred).... Tomasz and this forum must have good Karma!
> > > >
> > > > Also for K and T who stuck up for me when I was pelted with
> > rotten
> > > > fruit all those years ago!
> > > >
> > > > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
> > wrote:
> > > > >
> > > > > Thinking a little further on this.
> > > > >
> > > > > Unless there is a need for advanced matrix
operations 'psuedo
> > > > > matrices', using arrays with limited AFL matrix operations,
> > would
> > > > be
> > > > > sufficient for AB needs (arrays are faster and maintain
> > backward
> > > > > compatibility?).
> > > > >
> > > > > For advanced users the first phase would be the power
version
> > and
> > > > the
> > > > > method used would only store the core metrics with speed in
> > mind
> > > > (2,
> > > > > 3 or maybe 4 datapoints, as persistent arrays, depending on
> the
> > > > > objectives) and only calculate one metric, on the fly, from
> > them
> > > > i.e.
> > > > > the user defined objective function.
> > > > >
> > > > > All performance metrics would be derived from the core
> metrics
> > > and
> > > > > therefore able to be calculated in AFL so they would be
fully
> > > > > transparent to users.
> > > > >
> > > > > Default metrics could be built-in and rendered as tables
etc,
> > at
> > > > > phase II, for the benefit of newcomers, but as their skill
> and
> > > > > interest develops they could then easily drill down to the
> code
> > > > > behind the metric.
> > > > >
> > > > > Obviously the trade matrices are a precursor to advanced
> > > Portfolio
> > > > > Management in Phase III (RalphVince, MSA Analyser, van
Tharp,
> > > > > McDonnell, MonteCarlo Simulation or whatever takes the
users
> > > fancy).
> > > > >
> > > > > For my own use I intend to go right past phase II and
> implement
> > > my
> > > > > own Portfolio Manager (based on a compilation of my own
work
> > and
> > > > the
> > > > > work of people like RalphVince .... I am still working in
the
> > > > > background on BiNomial Simulation and if I am happy with it
I
> > > will
> > > > > use it in Phase III).
> > > > >
> > > > > Part of the rational, behind the idea, is that the time
value
> > > > > (processing) in the backtesting is saved, while the time
> value
> > in
> > > > > producing performance metrics is disposable (because the
> latter
> > > has
> > > > a
> > > > > lesser timevalue, the metrics of interest are based on
> > subjective
> > > > > choices and they change dynamically as new data arrives).
> > > > >
> > > > > I think it is a good idea but I am not 100% certain about
it,
> > not
> > > > > being a mathematician or programmer.
> > > > >
> > > > > I am becoming a little frustrated with AB (perhaps I am
> > > outgrowing
> > > > > it) and the Portfolio Backtester is a good example of one
> place
> > > > where
> > > > > that frustration is focussed.
> > > > >
> > > > > I have three ways I can go with it:
> > > > >
> > > > > - send it to AB as a suggestion (which is why I need
feedback)
> > > > > - implement my own backtester within AB (use a DLL?) ...
> maybe
> > > keep
> > > > > it private or publish it with open source code (possibly I
> > would
> > > do
> > > > > that via a team effort)
> > > > > - go to an existing open source charting project with my
ideas
> > > > > - intitiate my own open source charting project
> > > > >
> > > > > Since I am biased to open source, and therefore my
ideas/code
> > > would
> > > > > be in the public domain anyway, I have no reason not to
share
> > it
> > > > with
> > > > > AB and the AB community.
> > > > >
> > > > > If it is not a good idea then nothing is lost.
> > > > >
> > > > >
> > > > > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111"
<brian_z111@>
> > > wrote:
> > > > > >
> > > > > > There was some recent discussion about the need to learn
> more
> > > > than
> > > > > one
> > > > > > language to use AB.
> > > > > >
> > > > > > Just wondering if C++ Matrices could be used to store and
> > > > reference
> > > > > > trades, instead of Object Orientated Progamming, to make
> > things
> > > > > easier.
> > > > > >
> > > > > > C++ includes containers that can be considered matrices
> (such
> > > as
> > > > > arrays
> > > > > > and, in the Standard Library, vectors, lists, and maps)
OR
> > open
> > > > > source
> > > > > > C++ Matrix libraries are available.
> > > > > >
> > > > > >
> > > > > > Would it be possible to:
> > > > > >
> > > > > > - nominate buy/sell/buyprice etc in the first phase of
> > > backtesting
> > > > > > - run backtest over the sample space (limit space as
> defined
> > in
> > > > > setting)
> > > > > > - store trades P & L as % in binary files
> > > > > > - store time in trade (binary)
> > > > > > - store entry bar OR time (binary- only needed to display
> > > arrows
> > > > on
> > > > > > chart)
> > > > > >
> > > > > > Storing trades in binary form would be very fast (stored
as
> a
> > > > trade
> > > > > > matrix).
> > > > > > All metrics can be calculated from % P & L plus time in
> trade
> > > as
> > > > > > required so Money Management only needs to be applied in
> the
> > > > second
> > > > > > phase, if required.
> > > > > > Only the trade matrices need to be saved, with the
backtest
> > > > > settings
> > > > > > (also binary), for future reference, instead of the BT
> > reports.
> > > > > >
> > > > > > In the second phase performance metrics could be
calculated
> > as
> > > > > required
> > > > > > by referencing the matrix entries, either in total or as
> sub
> > > > > matrices.
> > > > > >
> > > > > > Matrix functions could be included in AFL and the
advanced
> > > > > backtester
> > > > > > would use them to reference the trades to create equity
> > curves
> > > > and
> > > > > > custom or default reports on demand (no need to re-run
> > > backtests
> > > > > for
> > > > > > custom reports OR when adding/deleting columns from a
> report).
> > > > > >
> > > > > > It might also be possible that trade P & L, and time in
> > trade,
> > > > > could be
> > > > > > stored in one 32 bit byte thereby save processing time
(the
> > > > > separate
> > > > > > pieces of info could be unpacked into the trade matrix
and
> > the
> > > > time
> > > > > in
> > > > > > trade matrix when required).
> > > > > >
> > > > > > Happily, the trade matrices could be rendered as tables,
> with
> > > > rows
> > > > > and
> > > > > > columns for visual reference/charting etc, which is much
> more
> > > > > intuitive
> > > > > > than referencing the Trade Object as we do at the moment.
> > > > > >
> > > > > > The matrices could use a full range of Matrix operations
or
> > > just
> > > > > some
> > > > > > of the basics for the AFL version e.g. referencing
> individual
> > > > > trades by
> > > > > > matrix M * N notataion (I don't know much about matrix
> maths
> > so
> > > > it
> > > > > is
> > > > > > up to the maths people to comment on possible uses for
> > advanced
> > > > > matrix
> > > > > > maths functions).
> > > > > >
> > > > > >
> > > > > > When data is added to the DB, or the sample range
extended,
> > > > > backtesting
> > > > > > could commence from the time of the last closed trade and
> > then
> > > > add
> > > > > new
> > > > > > trades to the matrix (this would save time by avoiding
the
> > need
> > > > to
> > > > > > repeat backtests).
> > > > > >
> > > > > > It is also a very nice format for exporting to Excel or
> > > advanced
> > > > > stats
> > > > > > packages like R or Matlab :-)
> > > > > >
> > > > > > Does anyone esle have any thoughts on the subject?
> > > > > >
> > > > >
> > > >
> > >
> >
>
------------------------------------
**** 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/
|