Skip to content
Prev 4561 / 15274 Next

Backtesting trade systems

I have been working on such a package too.  I am currently testing it, and 
was planning to have a small user group release in about a month or so.
The goal of the package {\tt\textbf{AlgoTrader}} is to provide such a
framework using an object oriented approach\footnote{See Section
   \ref{appendixProto} for a discussion on the design decision.}.  There
are two main classes.  An {\tt Algo} class from which all user
algorithms inherit and a {\tt Trader} class used for performace
tracking and reporting.  By convention, the parent classes {\tt Algo}
and {\tt Trader} are capitalized, while lower case names, say {\tt
   algo1} and {\tt trader1} are used for instances of these classes.
Conceptually, a model is represented by an algorithm and a trader.

The functionality provided in this package allows the user to define
multiple trading algorithms.  He could gradually refine these
algorithms by using the inheritance mechanism, or use the same
algorithms with different parameters to instantiate different
\code{Algo} objects.

The \code{Algo} object contains all the historical data necessary, a
set of parameters, functions that generate trading signals, and a set
of functions that modify the positions given a trading signal.  Using
an algorithm {\tt algo}, the user can create a {\tt trader} that uses
the algoritm over a specified time interval to arrive at a trading
decision for each time step.  A trade log is kept by the trader, so
that an analysis of the trading performance can be done.  The
\code{trader} has different methods to summarize/plot/evaluate his
performance.  For strategy selection or for tuning the algorithm
parameters, the performance of several traders can be compared side by
side.  As the \code{AlgoTrader} package does backtesting, it is best
if only deterministic trading algorithms are used so performance
results are reproducible.

Let me know if you want to take part in testing.

Thanks,
Adrian
On Thu, 16 Jul 2009, Mark Breman wrote: