Introduction

You have an idea for trading in your mind, one that can be put in full or partial algorithmic form; and you know how to code it as an strategy in some broker's technical solution; to focus on one take it Jforex. Now, what do you do? Do you start furiously to code in Java? Supposing that your algorithm is parametric, after you have a functional and tested code, do you start historical optimization runs? If you get a good set of parameters, do you put your strategy in Live Trade and wait for profits materialize?

This series of articles is my answer to such questions, spiced with tips, reflections and some recommendations for the analysis of the process and results, from my point of view rooted on my mathematical background. To maintain our feet on ground, I will use as conductor and example a system, call it Cyclop, in which I am working now, just before to go to Live Trade with it.


Starting point

Cyclop in reality is more a 'family' of systems that a single system, because it is highly configurable (can signal quite different market situations that offer -presumably- profitable entry points); is simple, with clear cut logic, and only needs a few indicators to work; it is based in loose observations of apparent invariant market conditions that I have perceived in the last four years in various pairs, mainly EURUSD, USDJPY, GBPUSD, AUDUSD and EURJPY. It uses only technical principles, extending greatly a very know Japanese candlestick pattern, and generates entry signals upon appearance of the pattern concomitant to some specific price conditions; with the entry moment it sets stop loss(SL) and take profit(TP) objectives. Setting down some of the configurable options, we arrive to the system which will be the example of these articles, which we will name Reverse Cyclop; it signals reverse market direction opportunities, and in the majority of its parameter phase space, it is a very stringent system, giving a very low signal rate (as we will view later).


Recomendation: Being simple and concrete do not equalizes to limited views; quite few clear conditions and requirements can cover extremely diverse market situations; objectively it is easier to implement, test and optimize a simple system than a complex one, and that pays out later, especially when it is the turn to analyze results, take lessons and perform actions.


The selection of Reverse Cyclop was not random; its logic is simpler than Cyclop, and its signals are easy to spot on charts, facilitating visual inspections for preparatory work; the market psychology implications behind the signal are compelling and in line with common beliefs; in fact, Reverse Cyclop came first, and after a long period of work with it I began to notice generalization venues that eventually guided me to the Cyclop concept.

So, after some visual convincing observations and paper trading tests, comes the need to systematize and work with the strategy on more automatic means. In Reverse Cyclop case, that came in the form of a very simple C++ program (call it C++ Simulator), which after reading 1H OHLC candle historic dataset files, generates a signal summary and performs a computation of closing conditions of each signal, allowing to calculate raw performance estimations; the simulated trades are all of the same size, so the statistics that can be extracted from it are a bit limited, and of low accuracy (no leverage and margin considerations, no spread information, no intrabar history, no volume, no commissions, no rollovers, some indetermination in the close of a trade if a bar comes with SL and TP inside its range, etc...). Some of the forthcomings of the software are addressed with the use of a configurable slippage computation, which used wisely can accommodate somewhat spread, commissions and order execution slippage. Basically what it gives is a very rough estimate of signal rates and raw results. The reason of using C++ and not Jforex directly was a combination of myself having more proficiency in C++ than Java and JForex, the idea that with C++ I have to code less things, and a desire to have a computation performance edge (which in retrospective is a very fortunate decision; more on this later).

A sample of the code of the C++ Simulator.


First performance data

After some tests, I came to the conviction that I arrived to something pretty interesting. I focused in EURUSD pair, which is my better pair (in real trading results and knowledge) and found parametric robust sets with fairly good performances (profit factors in the interval of 1.1 to 1.7, expected payoffs in the 2 to 8 pips range, Net Profit to maximal drawdown ratios greater than 1 and signal rates of the order of a few per week).

Raw performance statistics from a run on C++ Simulator using one of the first 'interesting' set of parameters found on EURUSD.

Let we stop here and do some analysis of what means “something pretty interesting”. It reduces to look at some performance metrics, and the information that at this stage of work can be extracted from them.

  • Net Profit(NP): the first and most important metric of all; what numbers can be seen as interesting? It depends greatly in the profile of the trader and its account, but also in its accompanying risk metrics; 100 pips per year can be seen as a good performance if it comes with very low risk (for example, a MAR Ratio of 5 or above). May be it seems rather poor (and having in mind an small account, in principle it is hardly enough to compensate all the work) but with a $1M account working with positions of 5M it converts in $50,000 of net profit (or 5%) approximately, only working with 1 pair (EURUSD) and system... if it comes with a maximal drawdown of less than $10,000, and lasts on time, we are looking probably at a cash cow. So, we have to be realistic with it; anything that can compound above 10% yearly with a -relative- low risk should make one jump out of the chair; it is a really fine result!
  • Expected Payoff(EP); as with its father metric NP, rather small numbers can be really good for the same reasons, and even as low values as 1 pip EP can be interesting if they come with great MAR Ratios and signal rates of little more than once per week. EP works better than NP when comparing different sets of parameters in runs generating a big difference in number of signals for the same time interval.
  • Maximal drawdown(MDD): with it we can compute three metrics that are really useful in this stage of the strategy study: NP/MDD ratio, Maximal Drawdown Depth(MDDD)=MDD/EP, and Winner Strike Recovery(WSR)=MDD/Average Win.
  • NP/MDD ratios over 1 are good starting points; even in the case of values very near of 1, such as 1.05; we must think that may be there is room to improve it with optimization of the parameters of the system, and that with an optimal money management policy we can improve it significantly. It signals that the risk starts to be worth the profit.
  • MDDD gives a very rough pessimistic estimate of the number of trades needed to recover from the maximal drawdown; if the signal rate is rather stable along the full period of trading, it can be used to compute an estimate of the recovery time: Expected (Maximal) Drawdown Recovery Time(EMDDRT)=MDDD/Signal Rate, which can be used as a rejector metric; what can start to be considered a good number depends greatly on the trader profile and its risk aversion; my tip is not to reject big numbers, because in my experience MDDD is quite pessimistic (in the sense that in a consistent winner system the majority of the drawdowns are recovered well before its EDDRT) and with a big improvement of the MDD it can be reduced significantly; in the case of Reverse Cyclop, I considered that less than a year EMDDRT is rather good, and indeed I found early parameter sets that showed that quantity.
  • WSR gives us an idea of the difficulty of a very quick recovery from a drawdown; the bigger the number the most difficult it will be (we will need more winning trades to recover). I find this metric useful in comparing parameter sets that give similar numbers for the other metrics above mentioned; also can be used as rejector; I think that values above 10 start to be too high except if we have a system with a very high win rate (above 70% to line a limit).

In the next part we will continue seeing how to combine this performance metrics with some additional statistics to extract useful information that will guide us in the next stage of our strategy development.

Translate to English Show original