A little surprised :) Thought I'd share and ask a NOT rhetorical question. - page 6

 
hrenfx:

Let's say you have two EAs identical in results in the Tester, one on indicators and the other all-in-one. The second works an order of magnitude faster.

There will be no order of magnitude increase of speed, only by 10-30%. Checked. The great speed gain makes us cumbersome to write two Expert Advisors, while the one "all in one" is practically useless for debugging and only to fight with errors.

 
Integer:

You obviously have some personal antipathy towards me. Oh, shit on me. What am I, the center of the earth, that you're overreacting?

Why don't I send you a picture of me so you can wipe yourself with it? I don't give a damn about your nervous outbursts. Don't waste your time and energy on them.

I urge you to be constructive, you're adults.

 
Integer:

There won't be an order of magnitude increase in speed, only 10-30%. Proven. Because of such great speed gain it is worth bothering to write two Expert Advisors, while the all-in-one one is practically not feasible for debugging, only to fight with errors.

The speed gain is highly dependent on the case. Nobody cancelled algorithmic optimization. If it's some kind of primitive EMA, the gain is minimal. But if it is something more complex, it might be an order of magnitude. It depends upon one's skill of algorithmic optimization. You should know where recalculations can occur and so on.

It helps a lot to write your own optimizer in this sense. For example, without algorithmic optimization, the all-in-one variant was 10 times faster (due to the programming language compiler) in my tester than the same all-in-one variant in the MT4 tester. After algorithmic optimization the advantage has increased by another order of magnitude.

I wouldn't bother with it for 10-30% in this case.

 

hrenfx:

1. The speed gain varies greatly from case to case. Algorithmic optimisation has never been cancelled. If it is some kind of primitive EMA, the gain will be minimal. But if it is something more complex, it might be an order of magnitude. It depends upon one's skill of algorithmic optimization. Know where there can be repeated calculations, etc. 2.

2. Writing your own optimizer helps a lot in this sense. For example, without algorithmic optimization all-in-one variant was about 10 times faster in my tester than in MT4 tester. After algorithmic optimization the advantage has increased by another order of magnitude.

I would not bother bothering with it for 10-30% in this case.

1) It depends on your skill of indicator writing.

2. If you accurately compare the performance of the MT tester and your own calculator for one strategy, you will be surprised with the optimality of the tester's algorithm (including the one provided by Academician).

 
Integer:

2. If you are able to correctly compare the performance of the MT tester and your own calculator for the same strategy, you will be very surprised at the optimality of the tester's algorithm.

What do you mean by correct? My calculator is >100 times faster than the MT4 tester, and has an error <1%. Is it justified or not?

MT4-tester has normal algorithms, but it is designed for universality and taking into account a huge number of factors that cause my calculator to have an insignificant (for estimating results) error.

A simple example: If I do not consider the order history in my EA deeply, why do I need it in the optimizer? Why do I need the emulation of a zero bar in the optimizer? We don't need all that, so it all comes down to a stupid for loop. It results in multiple speeds at the cost of <1% error.

We are in MQL5 forum, but I am not discussing the performance of MT5 tester in this discussion. I would like to see an official comparison of the two testers.

Эффективность многопотокового тестера стратегий MetaTrader 5 - MQL4 форум
  • www.mql5.com
Эффективность многопотокового тестера стратегий MetaTrader 5 - MQL4 форум
 
hrenfx:

1. What do you mean by correct? My calculator is >100 times faster than the MT4 tester, with an error of <1%. Is this justified or not?

MT4-tester has normal algorithms, but it is designed to be universal and take into account a huge number of factors, due to which my calculator gives an insignificant (for estimating results) error.

2. A simple example, if I don't look deeply into the order history in my EA, why do I need it in the optimizer? Why do I need the emulation of a zero bar in the optimizer? We don't need all that, so it all comes down to a stupid for loop. It results in multiple speeds at the cost of <1% error.

We are in MQL5 forum, but I am not discussing the performance of MT5 tester in this discussion. I would like to see an official comparison of two testers.

I want to see a comparison of the performance of the two testers so that we may understand what minimum number of manipulations in the tester is used to divide all timeframes into bars, to synchronize different symbols and to execute orders.

2. I hope this is not in the context of "I can write a better strategy tester than MQ".

 
Integer:

1. so that one could understand the minimum number of manipulations in the tester to ensure division into bars of all timeframes, synchronization of different symbols and execution of orders.

I'm sure the algorithms in the tester are excellent. The developers are not wasting their time optimizing it to the maximum - 100%. But everything is universal - for all variants. All variants are not necessary when we consider a particular case of MTS. This is the reason why they get wins by an order of magnitude in their calculations on the type of DUPLEX for.

2. I hope this is not in the context of "I can write a better strategy tester than MQ".

You have a preconceived notion of me as if I'm shitting on everyone everywhere. In this thread I am completely on the side of the developers. I perfectly understand the arguments of the topicstarter on the fundamental difference between the tasks of a tester and optimizer, but do not share his claims against the developers. My opinion - if necessary, you can always create your own tester-optimizer (not super-versatile, but fast) for yourself.
 
Renat:

A correctly written parsimonious indicator is better to be used internally, rather than put into the Expert Advisor code.

Transferring it into the Expert Advisor's code usually means that there will be implemented an extremely custom method of optimizing calculations, when the main amount of calculations is discarded and 300 bars of history are left (for example). In most cases, it will introduce errors, but the author usually does not pay attention to them. Unexpectedly, in real work it may turn out that the base indicator and its reduced copy in the Expert Advisor do not coincide.

I would agree with this, but there is one problem, which in some cases puts a bold cross on it.

It is absence of a normal realization of IndicatorCounted() - any moment it is reset to zero, you know about it very well.

I have followed another way - made my own data provider (quite optimized algorithm with circular addressing of data), made my function IndicatorCounted().

This approach has fully justified itself in real conditions.

Moreover, indicators are transferred practically 1:1, and there are no problems with their debugging etc.

Implementation of indicators as classes on the example of Zigzag and ATR

There is even some comparison of algorithms and approach in the tester:

P.S. As for the error, it depends on the indicator's algorithm. In most cases it is enough to ignore the first few bars, and the rest will coincide 1:1.

I specifically wrote check constructs for this purpose.


P.S.2 For ZigZag this is simply an indispensable way out of the situation.

I call it recalculate only when I need it, and it can return the expanded result, that only last point has been redrawn.

It allows optimizing other algorithms of an Expert Advisor.


P.S. 3 Regarding the MT5, I want to say that it's a great platform. But there are some serious bugs:

- critical bugs (of course they will be fixed in time)

- questionable approach to TERMINALMaxBar (I wrote about it that the situation is a dead end)

- lack of adequate IndicatorCounted() function (but I don't need it now at all)


P.S.4 I can't say anything about the tester, because I don't play the "optimization" game.

 
AlexSTAL:

I would agree with that, but there is one but that in some cases puts a fat end to it.

...

Where is the sense in it if according to your own tests the class embedded into Expert Advisor is slower than calling via iCustom()?

Another question, are you ready to rewrite all indicators in this style?

 
Integer:

Where is the sense in it if according to your tests the class built into the Expert Advisor is slower than calling through iCustom()?

Another question, are you ready to rewrite all indicators in this style?

The point is not in the tester, again! Not in the tester, but in real conditions, where history is downloaded and connection failures occur

About all the indicators - what's the problem?

Reason: