Repost of my comment at Steve Hopwood's Forex

This is a repost of my comment on the thread "R/MT4 indicator" on Steve Hopwood's Forex forum.

I have been busy working on my own trading ideas. Below is an example of a component that I am working on, which is part of a bigger picture to develop my own set of tools and indicators, for a complete trading system.

My system has six key components: (i) multi-pair; (ii) market strength; (iii) trend; (iv) momentum; (v) price action; and (vi) parameter-less. Each individual component is not new, however this system will be unique and different from others as it uses my own integration of custom indicators. I may post again to further elaborate on my system in the near future.

GradientVolatility Integrated With CSS

As mentioned above, one of my own trading idea was to integrate the GradientVolatility indicator with the CurrencySlopeStrength (CSS) indicator. See the attached picture.

Figure 1: Comparison of CSS and GradientCSS indicators

The CSS measures the strength of the currencies, however it does not measure the rate of change (or slope) of the strength. For example, in the picture, the CSS showed that AUD is negative and decelerating, but it does not show the rate of deceleration. The rate of change is captured using the GradientCSS.

There is a lot of potential for this indicator, as shown yesterday, when I gained a total of +73 pips from two long EurNzd trades based on their rates of change. See the attached history (ignore the other two non-EurNzd trades).

Figure 2: History of trades

The best part for trading on this indicator is that there won't be any optimization, as there are very few parameters. Hence, I do not have to worry about a high variance (over-fitting).

Note: There is a problem when calling the GradientCSS indicator with the iCustom() function, as it does not seem to like R very much. If anyone think that they can help, PM me.

(Edit: Just an update, I have completely rewritten the GradientCSS indicator from the ground up to use MQL code only, by replacing the lm() function from R. Then the iCustom() function should be able to work with this indicator.)

Download Indicator

The original GradientVolatility indicator can be downloaded here.

A New DSP Indicator in MT4

In this post, you will to understand how an MT4 indicator, specifically a Digital Signal Processing (DSP) indicator, is written and also how to interpret it on a chart.

Before I begin, let me digress a little bit. My DSP journey began in 1990s when I studied Computer Engineering at UNSW, Australia. For those not familiar with DSP, it is an engineering tool used to filter noise from signal and it has many practical uses in different industries. In 2011, when I started trading in the forex market, I purchased several books including a DSP trading book, titled "Cybernetic Analysis for Stocks and Futures" by John F. Ehlers. The book requires some familiarity with DSP from a practitioner's perspective, but I was lacking in DSP experience. I enrolled in the Coursera's "Digital Signal Processing" course, but I had to drop the course due to my personal commitments. For those interested, here is the course link.

The DSP indicator that I have written is based on a trading strategy from OneStepRemoved's "Cumulant Ratio" indicator. Although my DSP journey has taken a pause, I will read any interesting articles from a DSP practitioner's perspective.

Here is a snapshot of the USDZAR H1 chart with the CumulantRatio (CR) indicator below (Figure 1). I will explain to you the vertical red lines, which I have drawn on the chart after I explain how the maths work.

Figure 1: USDZAR H1 Chart

The maths is basically one equation:

where N is the period (or number of candles/bars), Xi is the individual price of each bar, Xo is the price of latest bar, and X_ is the average price of all the bars. The price may be the Open, High, Low or Close, in this case we use the Close price.

It is important to note that the numerator, which is a sum over the period N, divided by the denominator, which is also a sum over the period N, is the same result as when you divide the average of period N over the average of period N. I will explain why this is important later when we look at its implementation.

We implement the steps to the above math equation as follows:

(i) X_: this series is calculated using a simple moving average.

(ii) Xo: this series is calculated by using a step of the latest price every N period.

(iii) Numerator, i.e. Xo - Xi: this series is calculated by subtracting individual price of each bar from the second series.

(iv) Denominator, i.e. |Xi - X_|: this series is calculated by subtracting the first series from individual price of each bar.

(v) Equation, i.e. ratio: this series is calculated by dividing a simple moving average of third series by a simple moving average of the fourth series.

After mapping the math equation to the steps above, it is relatively straightforward to implement in MQL source code.

I will summarize the implementation in one paragraph, instead of explaining each step in detail. The simple moving average can be implemented using the iMA() function for prices, e.g. Close[], that are taken from a chart, or using the iMAOnArray() function for prices that are taken from a time series. The second step can be implemented using the MathMod() function and integer divisor (/) operator. The MathAbs() function can be used to calculate the absolute value in the fourth step. Unfortunately, in step five, MQL does not provide a sum on array function for time series, but we noted previously that we could use a simple moving average as the result is equivalent.

How to Interpret the Indicator on a Chart

The indicator has two user inputs:

(a) int CrPeriod: the number of bars to use for period N.

(b) int CrAlpha: a multiplier used to increase the range (enhanced visual and significance of the two lines, but it does not affect the histogram)

Figure 2: Custom Indicator Inputs

The indicator has two lines (green and silver) and one histogram (yellow):

(a) The green line represents the third series (Numerator), which can take any value from -infinity to infinity, but in practice, it has a limited range because it is a deviation from the latest price.

(b) The silver line represents the fourth series (Denominator), which can take any positive value from 0 to infinity, but it has a limited range because it is a deviation from the average price.

(c) The yellow histogram represents the fifth series (Equation), which can take any value from -infinity to infinity, and it has a much larger range than the two lines, because the Denominator is usually small, hence the ratio can be large.

Figure 3: CumulantRatio (CR) Indicator

In the next chart (Figure 4), I have marked three vertical red lines on the chart where the green line crosses the zero level. According to Shaun Overton, the green line

is only positive if the current price is “above” the sum of the last N bars. A negative position means that the current price is “below”.

(i) The first cross up showed a relatively weak up move, but you will note that the prices moved up strongly afterwards.

(ii) The second cross down showed a stronger down move, and the prices followed down strongly two bars later.

(iii) The third cross up weakly, and this is followed by the prices moving up strongly.

Figure 4: The green line crossing zero has preceded every big price move

At this preliminary stage, I do not yet fully understand how the indicator behaves and how to use it in trading. I will continue to monitor the relationship between the CR indicator and the prices. I think that you could use some additional filters before using it for trading, so as to prevent false signals.

Download Indicator

Please read the disclaimer first before downloading the source code or indicator.

You understand and agree to the following terms and conditions for use:
(a) you do not remove any of the copyright information from the source code, or attempt to commercialize the source code or indicator.
(b) you are allowed to modify the source code, but you do not attempt to commercialize any variation of the source code or indicator.
(c) I am not liable for any damages or losses as a result of you using the indicator or any variation of the indicator for any purposes.

The indicator can be downloaded here.

To code or not to code - that is the question

Recently, I had a request from a forum member of SteveHopwood.com to code an Expert Advisor (EA) based on an indicator.

I could probably code this EA (with no frills) in less than a day using the shell EA code. Programming has been my bread and butter for more than 15 years and I've grown to understand my clients very well.

First, clients rarely know what they want. In this case, the member is probably after the holy grail, and eventually this will lead to "scope creep" to add in more filters and trade management. Second, their idea is probably not new, and they are just reinventing the wheel. Third, they are probably not traders otherwise they wouldn't be searching for the holy grail. Hence, I would not even bother to code this EA.

However, if certain conditions have been met, I may be interested in coding an EA. First, the client must have used this system manually and has at least doubled his account recently. Second, he must not be reinventing the wheel, such as copying an idea from a commercial EA. Third, he should not request for me to put in place a fancy trade management as it does not make a lousy trading system better, i.e. martingale.

You may think that these conditions are excessive, but I am working on my own EA based on these criteria. First, I have doubled my account in manual trading using my own system. Second, I did not copy the idea or reinvent the wheel, as it is original based on my own system. Third, I do not have a sophisticated trade management to be profitable.

So, if you really think that your EA can be worthy of my time, then prove to me that your system is as good as the above system, and have met my criteria. Otherwise, I suggest you hire a no-frills programmer who has no trading capability.

A Journey of a Thousand Miles Begins By Taking One Step at a Time.

It has been more than a year since my last post, and I apologize for the long gap between this post and the last one. However, the long gap does not reflect the difficult journey that I have had in overcoming the challenges of automated trading. The difficulty lies in the fact that as a systematic trader, you have to face an uncertainty in your monthly income, and there is no network of support of friends to encourage you.


I had been following the forum DonnaForex.com as a member for some time now, and there is no shortage of interesting robots being discussed, dissected and analyzed in that forum. The forum is unique in a sense that the moderator Donna is very active and does moderate all discussions, hence it appears to be an orderly forum. Initially, I found a network of support from members of this forum, as there appears to be many members, who are serious about discussing the pros and cons of every robots. However, over time, the discussion had turned ugly into more about which robot is better (and who is making more money), but very little about the actual pros and cons of the robots.

I had learned the Metatrader 4 language, called MQL, relatively quickly due to my programming experience. Motivated by my new knowledge, I decided to create a package that could overcome the shortcomings of a demo account. One of the limitations of using a demo account is that there is no or very little slippage, hence it does not reflect actual trades. Also, there have been books written about how a Forex broker utilizes tools to perform stop-hunting on live accounts, and this again does not happen on a demo account. The result is that a "profitable" robot on a demo account can quickly become a loss-making robot in a live account. Hence, I decided to create a 'Ghost' MT4 package, which utilizes a live account for tick data, but orders are processed by my package and stored in an SQL database. The benefit of this is that the orders created by a robot are never sent to the broker, but they are intercepted and processed by my 'Ghost' package, and sent back to the robot. Hence, the whole process is transparent to the robot and as far as the robot is concerned, it is as good as trading on a live account.

One limitation of the 'Ghost' package is that I am using a third-party MT4 SQL driver for an SQLite database, and the external functions from this driver are limited. For example, the driver lacks an external function for a rollback feature in the SQLite database. Another limitation is that the records cannot be accessed concurrently.

I am having a hard time juggling my tasks as I have about a dozen things to do in Automated Trading. But that's not what I want to write about in my blog today. Instead, I would refer you to a book which I am reading called "Fibonacci Analysis" by Constance Brown. My blog will be relatively short today as I would like to finish reading the book.

This topic is interesting, to me, not because of the Fibonacci Analysis by itself, but because of the author's own intrincacies on how it should be applied in the trading room. The challenge for me is how the Fibonacci Analysis (as shown by the author) could be designed and implemented as an Automated Trading tool.

After reading the first few chapters, my initial thought on design is that the initial range of the Fib analysis has to be identified correctly as it is crucial to the rest of the analysis (according to the author). However, it appears that the range is rather subjective (for example, while most practitioners would use the highest high as a starting point, the author may use the second highest high based on her judgments). As a designer, my goal is to translate the author's judgements into a specification that can be easily implemented as an algorithm.

Ok, time to hit the books and finish reading what I started (hopefully by tomorrow).

Let me fill you in on some of the other things which I am doing; programming an indicator (MT4) based on candlestick and testing it; programming a custom indicator for a colleague; running a portfolio of Expert Advisors (EAs) on my live accounts; trialling a new signal service provider for two weeks; reading several books on Tradestation, candlesticks, and Fibonacci by different authors; and ordered 2 books from Amazon on how to build a robust EA and MIDAS analysis.

For my next blog, I will try to design a specification on the Fibonacci Analysis.

My Most Difficult Challenge in Automated Trading

One of the most difficult challenges, at least for me, in Automated Trading is to allow the automated scripts (or robots) to run without any human intervention with its open/close signal logic.

Take a recent example, I decided to close an opened buy trade - which was placed by my robot - early for a small profit, instead I missed out on a big run up (several times my profit). Talked about a missed opportunity. Clearly, I failed to trust the capabilities of the automated script and let my human emotions take control instead.

There are two camps of traders in this area: (1) traders who will never interfere with a robot's trade (let's call them hard traders for simplicity); and (2) traders who will always trump the robot with human discretion (let's call them soft traders).

In the first camp, I have seen hard traders who would rather watch their very profitable trade turn into losses than to interfere with the robot. The typical wound-healing statements made by them are that as the robot had been backtested and had produced a historically profitable equity curve, these losses are just part and parcel of the automated script. My problem with having this view is that there is no evidence that interfering with the robot's trades will diminish its long-term profitability. In fact, the opposite could be true - it may increase the robot's long-term profitability - and unless someone publishes data to show that human discretion will result in a direct drop in the equity curve of the robot, I will continue to have difficulty accepting the hard trader's view.

In the second camp, I have seen soft traders who would discern every open/close signal generated by the automated scripts, and place a trade manually after assessing the current market conditions. Again, I find the soft trader's view hard to accept as you may have lost some profits during the assessment as the market moves against you. Also, the benefits of an automated script are precision and speed, both of which are not utilized by the soft trader. This, to me, seems to defeat the purpose of having an automated script in the first place.

I have identified several factors to discern whether I should interfere with an automated script:

1) Upcoming news or events that may work against the robot (wrong direction).
2) Volatility (whiplash profitable trades turn into losses).
3) Volume (too thin to trade).
4) Two robots that may have conflicting trades (one opens a long, and the other opens a short).
5) Major resistance or support levels reached.

These are in order of importance (hence I would consider 1 as more important than 5).

In conclusion, my view lies somewhere between the two camps. However, as a trader with an engineering background, I would imagine the future with an automated script that is capable of processing huge amounts of data in order to make decisions as close to humanly as possible. This would be made possible by improving technology, which in turn would lessen my challenge of having to trust the robots to run without human intervention.