Enhancing Stability and Robustness of Automated Trading Robots: Strategies, Challenges, and Insights
- Techniques for Pausing Trading : Seeking Community Insights
- Unlocking Effective Highs and Lows Identification in Development Process: Seeking Insights and Strategies
- Navigating Mobile Trading: Seeking Guidance
Forum on trading, automated trading systems and testing trading strategies
Can't Find Any Profitable EA on MQL5 in past 5 years.
Sergey Golubev, 2019.04.14 08:26
There are Raw Ideas. It is the ideas about the following: attach indicators to the chart and see that it may be profitable.
There are Elaborated/Proven Ideas. It is when someone was trading this indicators' setup during the several days/or weeks/or months on demo account (and, in some cases - on real live account). I am not talking abouty backtesting. Raw idea became to be a Elaborated Idea by trading (at least - on demo).
Why to trade? To define the trading rules, and to know: when the system will let you win, and when you will lose by using this system (and why).
- Some people prefer to do it in public threads (coding, testing, trading) and finally - post/upload everything as the source codes on the public threads.
- The other people are doing in privately (with no one can see it), and it is always about some kind of believing for example (do we trust those people or not).
- And there are some people who do not do anything. They just attached indicators to the chart and see that it is good ...
I recommend checking the brokers spread etc and carrying out a genetic optimisation test. If possible carry out a monte carlo simulation and a what if scenario simulation.
What I did with my bot.
Also an EA should be able to run on any symbol. It should be coded in such a way that your code adapts to the symbols and accounts specifications.
This was a big thing for me when I started coding my own EAs vs using ones from the Market or CodeBase. Many are coded to use points or pips/percentages as units for any kind of distance, i.e., not just stop loss or take profit, but the size of a candle, or the distance from a moving average, etc. The problem is that these units are radically different between different symbols and brokers.
For the most part, I now try to code everything either as an ATR multiple of some kind, so that it ports better from symbol to symbol without having to work so hard to try to even figure out the right range of values for a particular input. Sometimes, depending on the strategy and timeframe, that may mean using longer periods to calculate the ATR, e.g., if I'm trading on M1, I may use values of 60 on up to 240 for the periods for the ATR, so I have something more stable, less subject to momentary fluctuations.
Similarly, it's a good practice to always have an option for risk as a % of the account, or a fixed dollar/currency amount, not just fixed lot size. Again, this makes it much easier to apply to different symbols without worrying about screwing up the math.
The biggest risk in automated trading is always that past performance is no guarantee of future results, i.e., your live trading won't live up to your backtesting.
Besides the usual practices of backtesting in out of sample data and being careful not to overfit (that's a whole other discussion of its own), I've increasingly become mindful of the LR correlation metric in the backtest, and I'm planning to start implementing R-squared as a custom OnTester() metric. I've come to the point that I feel like optimizing for maximum consistency is more important than maximizing profitability.
I've also found that so long as a) the algorithm isn't overly complex, and b) it's at least moderately profitable with the default values, that algos that have a higher LR correlation / R-squared over a decent period of time (say, 3 years) tend to perform better on out of sample data, as well.
- www.mql5.com
This was a big thing for me when I started coding my own EAs vs using ones from the Market or CodeBase. Many are coded to use points or pips/percentages as units for any kind of distance, i.e., not just stop loss or take profit, but the size of a candle, or the distance from a moving average, etc. The problem is that these units are radically different between different symbols and brokers.
For the most part, I now try to code everything either as an ATR multiple of some kind, so that it ports better from symbol to symbol without having to work so hard to try to even figure out the right range of values for a particular input. Sometimes, depending on the strategy and timeframe, that may mean using longer periods to calculate the ATR, e.g., if I'm trading on M1, I may use values of 60 on up to 240 for the periods for the ATR, so I have something more stable, less subject to momentary fluctuations.
Similarly, it's a good practice to always have an option for risk as a % of the account, or a fixed dollar/currency amount, not just fixed lot size. Again, this makes it much easier to apply to different symbols without worrying about screwing up the math.
Like you said, it depends on the strategy.
In some cases, like a trailing stop calculation, you may want it to be more reactive, even down to like 5 periods or so, so that it responds quickly to a consolidation.
In the case I described, I'm not trying to be reactive to current market conditions, but using ATR to easily get a sense of appropriate scale. I don't want to have to figure out the appropriate scale for stop loss in points on every symbol and timeframe I test on. Some, a range of 1-100 makes sense; others, it's more like 100-10,000, in steps of 1000. But if I'm trading on the M1, I certainly don't want to set that since of scale based on just the last 15 minutes -- I probably want at least, say, 4 hours (in fact, ATR(240) is a common starting point for me when trading on M1), or on the H1, I don't want it just based on today, but more like a week, so ATR(120) is what I often use.
Tl;dr: a much longer ATR period gives a good general sense of scale that ports well across different symbols and timeframes.
Like you said, it depends on the strategy.
In some cases, like a trailing stop calculation, you may want it to be more reactive, even down to like 5 periods or so, so that it responds quickly to a consolidation.
In the case I described, I'm not trying to be reactive to current market conditions, but using ATR to easily get a sense of appropriate scale. I don't want to have to figure out the appropriate scale for stop loss in points on every symbol and timeframe I test on. Some, a range of 1-100 makes sense; others, it's more like 100-10,000, in steps of 1000. But if I'm trading on the M1, I certainly don't want to set that since of scale based on just the last 15 minutes -- I probably want at least, say, 4 hours (in fact, ATR(240) is a common starting point for me when trading on M1), or on the H1, I don't want it just based on today, but more like a week, so ATR(120) is what I often use.
Tl;dr: a much longer ATR period gives a good general sense of scale that ports well across different symbols and timeframes.
Right, I agree on that. - But also there is some "disagrement" I see. - If you take the ATR with 240, on a 1M and you transition from London evening to Syney night, you will have a wrong scale. - Same goes for London open... Or do I see this wrong?
Right, I agree on that. - But also there is some "disagrement" I see. - If you take the ATR with 240, on a 1M and you transition from London evening to Syney night, you will have a wrong scale. - Same goes for London open... Or do I see this wrong?
No, you're correct. That could be accommodated for somehow if you really wanted to. In the particular case I'm implementing it for, though, I'm actually trading n minutes before the NY close, so the 240 is appropriate - it's the NY afternoon session.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use