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

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



PureBytes Links

Trading Reference Links

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@xxx> 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/