--- In
amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> 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@>
> 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?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>