[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[amibroker] Re: Trade Series Matrix Using C++



PureBytes Links

Trading Reference Links

> 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.

It sure would be a lot of fun breaking the current world speed 
record, for backtesting, with an open source software package :-)




--- 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?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



------------------------------------

**** 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/