How best to combine leading/lagging indicators in my EA? | Forex Factory

Options

Permalinks
Print Thread

Similar Threads

Lagging Indicators -vs- Leading Indicators 48 replies

Need help, I am trying to combine 2 indicators into 1? 2 replies

Reply to GolfCoach (How to combine indicators) 2 replies

Possible to Combine Indicators in MQ4? 4 replies

how do I combine indicators in one pane 1 reply

Attachments: How best to combine leading/lagging indicators in my EA?
Exit Attachments

How best to combine leading/lagging indicators in my EA?

  • #1
  • First Post: Jul 4, 2020 10:39am Jul 4, 2020 10:39am
SUMMARY

  1. In my (fully working) MQL4 EA, when i have an indicator that detects a trend early, how best can I confirm it with another indicator that detects a trend at a later time (at a different bar)?
  2. If the second (lagging) indicator is coming late, should i even bother confirming it with one that comes late, since it defeats the purpose of getting early signal?


DETAIL
What it is:

  1. Hi, I've created an EA that contains trend detection logic for about a dozen different indicators. (eg moving averages, ADX +/- crossovers, alligator crossovers, etc). In the EA input settings, you can mix and match the indicator method you want to use (set true / false ).

The way it works:

  1. On the open of every bar, I check for what trend is detected by each of the selected methods ( i usually use the previous bar's PRICE_CLOSE for my signals). If there is a corroboration across all of them (eg: all of them suggest an 'UP' trend), then I place my order, with a trailing stop stop loss that kicks in after 'X' pips of profit are secured (x is also an input).

Where I need help:

  1. These indicators get signals at different times, sometimes at different bars. In these cases, I wont get signal confirmation across all of them. In some cases, i have added logic to "Look back" at previous bars (using the 'shift' property that is included in most MQL4 indicators). This way i can look back a few bars to see if there was signal detected then. Should i continue going down this path? If so how many bars back should I look? Or is there, in fact, a better way?
  2. A more general question: should I even confirm a leading signal with a later signal? It seems that i would lose the benefit of early signal since i am waiting for a late confirmation. For example: a leading OBV+OBV MA crossover with a lagging moving average crossover.


Thanks in advance.

  • #2
  • Jul 27, 2020 11:46pm Jul 27, 2020 11:46pm
. . . Anyone?
  • #3
  • Jul 28, 2020 12:30am Jul 28, 2020 12:30am
Quoting kasinath
. . . Anyone?
I don't think all indicators will give trade signal, even in a trend all at the same time. But I believe you will have to post the ea to complete your own question. Only then and after studying it can any more comments be made. Thanks and
Regards
  • #4
  • Edited 9:26am Jul 28, 2020 5:54am | Edited 9:26am
Quoting kasinath
. . . Anyone?
Attempt to answer your 1st question:

Adding "look back" logic is definitely possible but over-complicates signal detection. What I do instead is the following: All my indicators carry a "trend direction" and "trend duration" indication (in the same buffer, for an example see the header documentation in my ALMA). With this I cannot only see whether a signal occurred but also when in the past it occurred, without traversing back in time.

This makes it very easy to combine signals that occurred at different times in the past. Let's say I want to combine ALMA (first) + SuperTrend (following). I would wait for the later signal (the SuperTrend), and when it occurres I can easily check the ALMA if a signal in the same direction exists. If I wanted to I could also limit the time between both signals by checking the trend duration. If you want to combine more than two signals, you always wait for the last one (or maybe for more than only one), and when your last signal occures you check if any/all of your required leading indicators gave matching signals.

This approach is very easy to check at runtime and you don't have to store/carry any intermediate state in your EA. Backside: This approach doesn't work with built-in indicators. In anyway you will quickly come to the realization that everything built-in into MT4/MT5 is not sufficient for serious trading.

Until now I have not seen any indicator anywhere in the internet coded like I do, but I really think that this way is a must.
Inserted Code
if (IsBarOpenEvent()) {
   // get the leading ALMA trend
   int trendALMA = iCustom("ALMA", ..., MovingAverage_MODE_TREND, 1);
 
   // get the following SuperTrend trend
   int trendSuper = iCustom("SuperTrend", ..., MovingAverage_MODE_TREND, 1);
 
   if      (trendALMA > 0 && trendSuper == 1) twoSignals(MODE_UPTREND);
   else if (trendALMA < 0 && trendSuper == -1) twoSignals(MODE_DOWNTREND);
}
 
void twoSignals(int direction) {
   if (direction == MODE_UPTREND) {
      // go long
   }
   else {
      // go short
   }
}



Attempt to answer your 2nd question:

That's a matter of experience and personal taste. Imho adding a second indicator confirmation is like adding an additional filter - rarely a good approach. Filtering bad initial signals usually doesn't improve your results. It implies that the second filter used standalone represents a profitable system by itself, which most of the time is not the case. If it was you wouldn't need two indicators in the first place.

But there is another way to see it, where a "second" signal can make sense: The leading indicator should be on a higher dimension (length or timeframe) then the following indicator. In this sense it's strictly not leading/following but from your program logic point of view it's still "check first" + "check second".

Example: Use the signal of an ALMA(30) (second signal) but only take a long signal if price is above an SMA(200) (first indicator). Hopefully my explanations are understandable. In short: you have to decide whether it makes sense and there is no general answer.
It takes blood, sweat and enough tears to wash away the blood.
  • #5
  • Edited 10:33am Jul 28, 2020 9:56am | Edited 10:33am
Quoting emmzett
{quote} ....a "trend direction" and "trend duration" indication (in the same buffer, for an example see the header documentation in my ALMA). With this I cannot only see whether a signal occurred but also when in the past it occurred, without traversing back in time. This makes it very easy to combine signals that occurred at different times in the past.
This is fantastic. A lot more than I was hoping for in an answer! Thank you.

I had considered something like a trend duration but quickly dropped that idea since i figured a lookback was easier (as you can imagine i am using the inbuilt indicators). Thanks for the sample code, this will give me a reference points as I may re-write one or two of these indicators to include duration.
Also, I had seen your ALMA and Supertrend on github, and had bookmarked to check it out at some point. Will dig deeper into that, it does seem interesting.

Quoting emmzett
{quote} you will quickly come to the realization that everything built-in into MT4/MT5 is not sufficient for serious trading.
I am realizing this every day. Sometimes I feel that Metatrader is flat-out a bad idea for serious trading. But that is a topic for another day on another thread. I am still only a few months into this, so let me pace myself and get up to speed first.

Quoting emmzett
{quote}The leading indicator should be on a higher dimension (length or timeframe) then the following indicator. In this sense it's strictly not leading/following but from your program logic point of view it's still "check first" + "check second"
This is great. This makes so much sense, and you answered my question i have asked on another forum but got no useful answers!

Quoting emmzett
{quote}Hopefully my explanations are understandable. In short: you have to decide whether it makes sense and there is no general answer.
Your explanations are understandable, and they are exactly what I needed to give me new motivation/energy as I learn and explore new ways to build strategies.

It's people like you that make communities like this thrive. Thank you so much for the guidance.
  • #6
  • Jul 28, 2020 11:00pm Jul 28, 2020 11:00pm
Quick one, MZ:

I actually want to give ALMA a try, but compilation is failing because of the "." in some macro definitions (of sizes.mqh).
eg:
Inserted Code
// MT4 structs
#define FXT_HEADER.size                    728
#define FXT_HEADER.intSize                 182

This makes sense to me, as I think C/C++ doesnt like "." in macro definitions, if I remember correctly.

How do you work around this?
  • #7
  • Edited 11:52pm Jul 29, 2020 3:51am | Edited 11:52pm
Quoting kasinath
Quick one, MZ: I actually want to give ALMA a try, but compilation is failing because of the "." in some macro definitions (of sizes.mqh). eg: // MT4 structs #define FXT_HEADER.size 728 #define FXT_HEADER.intSize 182 This makes sense to me, as I think C/C++ doesnt like "." in macro definitions, if I remember correctly. How do you work around this?
To be backward compatible with old terminal versions (I use them a lot) I compile with an old and pure MQL4 compiler (see the bin directory). In your case just download a release version of the framework and use the precompiled binaries. You also need to copy everything from the libraries folder into your terminal's library folder.
It takes blood, sweat and enough tears to wash away the blood.
  • #8
  • Jul 29, 2020 9:40am Jul 29, 2020 9:40am
Quoting emmzett
{quote} To be backward compatible with old terminal versions - I use old versions a lot - I compile with an old compiler (see the bin directory). In your case just download a release version of the framework and use the precompiled binaries. You also need to copy everything from the libraries folder into your terminal's library folder.
Ah, I had a feeling that the compiler version may be it. Was also looking for pre-compiled binaries. Thanks!
  • #9
  • Aug 5, 2020 12:26am Aug 5, 2020 12:26am
Quoting emmzett
{quote} ...In your case just download a release version of the framework and use the precompiled binaries.....
Quick one, albeit only somewhat related:

Should the pre-compiled SnowRoller binary work with recent versions of MT4?

I'm running MT4 v1280, and when I attempt to load the 'Expert Properties' panel for the EA, I get the following errors in the journal.

2020.08.04 22:21:17.308 Tester: cannot load Experts\SnowRoller
2020.08.04 22:21:17.308 cannot open file 'C:\....\Experts\SnowRoller.ex4' [2]

I can troubleshoot on my own, but just wondering: is this to be expected?

Thanks.
  • #10
  • Edited 8:04am Aug 5, 2020 1:33am | Edited 8:04am
Quoting kasinath
{quote} Quick one, albeit only somewhat related: Should the pre-compiled SnowRoller binary work with recent versions of MT4? I'm running MT4 v1280, and when I attempt to load the 'Expert Properties' panel for the EA, I get the following errors in the journal. 2020.08.04 22:21:17.308 Tester: cannot load Experts\SnowRoller 2020.08.04 22:21:17.308 cannot open file 'C:\....\Experts\SnowRoller.ex4' [2] I can troubleshoot on my own, but just wondering: is this to be expected? Thanks.

  1. MQL4.0 will always be supported in all MT4 versions, so yes - it works in the latest build.
  2. [2] is a system error and means "Cannot load file/file not found"

Most probably you experience a data folder issue. At startup the terminal logs the currently used data folder in the terminal's "Journal" log tab, and tries to load MQL programs from that folder.

A good way to start is to clone/download the project, setup a separate terminal in portable mode (so you can continue to work with your current terminal without interfering with data in your data folder) and to symlink "mql4", "sounds" and "templates" from the downloaded project to the portable terminal's installation dir.

Attached Image


A .set file for EURUSD to give you an idea of the input syntax (see also the input section in the sources). This .set file requires the "Jurik Moving Average" to be in the indicators folder:
The most simple case for "StartCondition" is empty (immediate start) or only price (in both cases "AutoRestart" would need to be "off").
Attached File(s)
File Type: zip SnowRoller EURUSD long.zip   < 1 KB | 394 downloads


Before the first run execute the script "Config.Terminal" and configure your brokers's timezone in "global-config.ini". See the documentation in "config/global-config.example.ini". Currently supported timezone ids:
Inserted Code
America/New_York
Europe/Berlin
Europe/Kiev
Europe/London
Europe/Minsk
FXT             ; Forex Standard Time: Europe/Kiev with DST of New York
FXT-0200        ; that's London with DST of New York (rarely used)
GMT

If "UnitSize" is set to "auto" it reads the unitsize config from one of the config files (doesn't matter which one):
Inserted Code
[SnowRoller]
Unitsize.EURUSD = Leverage 5.7
Unitsize.GBPAUD = 0.02
Unitsize.GBPJPY = Leverage 5.0
Unitsize.XAUUSD = Leverage 5.7      ; 0.04 lot/1,000.00 EUR account equity


Since the last release I moved all broker configurations to the config files. Will see if there's time today to upload a new release.

edit: Added a link to the "portable mode" documentation.
It takes blood, sweat and enough tears to wash away the blood.
  • #11
  • Aug 5, 2020 8:05am Aug 5, 2020 8:05am
Quoting kasinath
...
Tagged a new release v0.105
It takes blood, sweat and enough tears to wash away the blood.
  • #12
  • Aug 5, 2020 10:00pm Aug 5, 2020 10:00pm
This is great. Thanks for writing out the steps so clearly and thoughtfully.

And as always, your answer gave even more than I asked for. This set file will come in very handy.

I'll try this all out tonight!
  • #13
  • Aug 7, 2020 1:30pm Aug 7, 2020 1:30pm
@emzett:

I was able to get snowroller running, but with some errors ( will keep troubleshooting before i mention them here --it could be my fault ).

One question i have : is it a hard requirement to have bash? I see one of the configuration settings is for the path to Bash. I don't have bash, and it seems its no longer available for windows 10 (instead something called WSL?). If it is a hard requirement, would GitBash suffice?
  • #14
  • Edited 7:39am Aug 8, 2020 1:26am | Edited 7:39am
Quoting kasinath
@emzett: I was able to get snowroller running, but with some errors ( will keep troubleshooting before i mention them here --it could be my fault ). One question i have : is it a hard requirement to have bash? I see one of the configuration settings is for the path to Bash. I don't have bash, and it seems its no longer available for windows 10 (instead something called WSL?). If it is a hard requirement, would GitBash suffice?
Bash is only needed when sending email via the function SendEmail(), otherwise you may just ignore it. SendEmail() uses the Cygwin package "email". That package requires working command output redirection which is broken in cmd.exe if the redirected stream contains special characters. Thus the need for a real shell application like in Linux. Whether or not WSL is "real" remains to be proven. I have my doubts...

With an external email program you can send mail to whatever account type you want and are not limited to the restrictions of the terminal's built-in mail functionality.

Yes, Git Bash is perfectly fine. I use both Git Bash and Cygwin.

See also:
Inserted Code
[Mail]                              ; The mail configuration to use when sending email via stdfunctions::SendEmail()
Sendmail = /bin/email               ; MTA configuration in "/etc/email/email.conf"
Sender   = {email-address}
Receiver = {email-address}
It takes blood, sweat and enough tears to wash away the blood.
  • #15
  • Aug 8, 2020 1:54am Aug 8, 2020 1:54am
Quoting kasinath
@emzett: I was able to get snowroller running, but with some errors ( will keep troubleshooting before i mention them here --it could be my fault ). One question i have : is it a hard requirement to have bash? I see one of the configuration settings is for the path to Bash. I don't have bash, and it seems its no longer available for windows 10 (instead something called WSL?). If it is a hard requirement, would GitBash suffice?
Always run DebugView from Sysinternals (start it with admin rights) parallel to the terminal. If something goes wrong in the framework DebugView is the place to look for error messages.
It takes blood, sweat and enough tears to wash away the blood.
  • #16
  • Last Post: Aug 8, 2020 2:32am Aug 8, 2020 2:32am
Quoting emmzett
{quote} Always run DebugView from Sysinternals (start it with admin rights) parallel to the terminal. If something goes wrong in the framework DebugView is the place to look for error messages.
This is tremendously helpful, and the missing link for my troubleshooting.
Thanks for this!

Also, thanks for the insight on what bash is used for by the framework. It makes sense (I am very familiar with sendmail, I used to write broadcast emailers, once upon a time). I won't need it for now, and i'm glad i don't have to install WSL, ha.
0 traders viewing now