Features of the mql5 language, subtleties and tricks - page 127
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
A whole zoo ate at this topic. Would have thrown those bars out a long time ago, since there is access to custom ticks.
I'm generally convinced that the best tester implementation for most robust strategies in terms of quality/fastness would be one based on minute bars, I think that says it all. Of course, bars with high/low asks and bids, not just bids as in MT
As a beginner you are the one reasoning, because in real life it will be worse than in the tester, as close to the story as possible. It's almost an inevitability that comes with experience. That's exactly how my approach works: its result is slightly worse than the result on real ticks, but not to the extent that it can be regarded as an independent system-breaking factor. Experienced traders will appreciate this approach, I'm sure.
Well, it's obvious that we are in different weight categories when it comes to working with the Tester and custom symbols.
I accelerate backstops by orders of magnitude without any loss of accuracy. I backtest and trade with pip precision due to virtualization. I don't share the source code out of the blue.
Of that I have no doubt and I am very grateful to you for that. But sed magis... as they say :)
In tests it is often more rational to take the worst spread per minute and that's a fact. If the quotes are noticeably curved, then you need to change the quotesWhen testing, it is often more rational to take the worst spread per minute and this is a fact. If the quotes are noticeably curved, you need to change the quotes
This is so easy to check. You take real ticks and run on them - you've got a benchmark.
And then on bars with a worse spread and a different spread formation rule. Where it is closer to the benchmark - there is a better variant.
This is so easy to check. You take real ticks and run on them - you've got a benchmark.
And then on bars with a worse spread and a different spread formation rule. Where it is closer to the benchmark - there is a better variant.
From the programmer's point of view - yes, but not from the trader's one. This is a spherical etalon in a vacuum, and the trader prepares for the fact that his market will be checked immediately after the launch into the real account. However, I think we've already discussed everything here )
This is so easy to check. You take real ticks and run on them - you've got a benchmark.
And then on bars with a worse spread and a different spread formation rule. Where it is closer to the benchmark - there is a better variant.
Although, if I immediately understood how to attach your ready-made solution to my EA, I probably would not have invented an amateurish bicycle. But judging from what I've read in your threads, I'm not the only one who has such a problem =))
When you made the dubbing of MT4 performance in MT5 - it's just priceless, I personally don't run MT5 without your library at the moment (no decent one of my own yet)). I don't have time to understand virtualization and testers, especially with custom symbols.
...as a result of the tester feeding the EA with the minimum spread per minute bar instead of the realistic maximum spread
And why the minimum? As far as I know, the average spread per bar is stored in bars. The average is the closest to reality, rather than the maximum (as you suggest) or minimum (as another friend suggests).
And in general, it is better to write the spread that was at the moment of transaction. If the trade is executed at bar opening, then spread of the first tick should be written. If it is at closing, then spread of the last tick. If everything is mixed - then OHLC mode should not be applied.
And why the minimum? As far as I know, the average spread per bar is stored in bars. The average is the closest to reality, rather than the maximum (as you suggest) or minimum (as another friend suggests).
And in general, it is better to write the spread that was at the moment of transaction. If the trade is carried out at bar opening, then spread of the first tick should be written in bars. If it is at closing, then spread of the last tick. If everything is different - then OHLC mode should not be applied.
We deal with triggering of lapses, including stops, take and limits, on the boundaries of these bars between open and close; therefore, we need adequate levels of high/low and realistic spreads. And according to the rule: if a guaranteed adequate one cannot be set, the version worse, not better, should be used, it is an axiom. In real ticks it would of course be better, but the loading speed, the number of operations and the volume of data are incomparable in these modes. This is unnecessary, it is not required for normal trading tasks. For most realistic tasks minute bars are enough.
I have checked subjectively, and the spread is exactly the maximum per minute, not the average check for yourself and see for yourself.
I've checked in detail and the spread is the maximum per minute, not the average - check it yourself and see for yourself.
I don't really understand: first you say there is a minimum, and now you say there is a maximum?
If you can not set a guaranteed adequate one, then you should take the one that is worse, not better, and this is an axiom
I don't quite get it: first they said there was a minimum and now there is a maximum?
I must have made a typo.