MT5 forward testing bugs. - page 2

[Daniel Csigo]

Hello!

I experience the same errors during optimization forward testing. A lot of forward test matches with it’s own single test result, but lot of forward test missmatch. If I click on the forward result and choose Run single test and I get different result with the same code and settings. 

Backtest part is always correct and gives the exact same result, but forward results are many times different and the optimization’s forward result is wrong.

So like tanner gilliland mentioned, the best optimization results’ forward tests are incorrect as well. 

I use generic optimization with Custom function mode.

Any idea how to fix this bug?

[tanner gilliland]

Hi Daniel, I'm curious if you see the same patterns in your forward testing as I do. For me during the first 512 passes there are more passes being shown completed in the agents tab than in the final number at the bottom. From 512 passes to 1024 passes the same thing happens again but it also does passes that should be at the end of the test. (it will look like you can take the passes from 512-1024 and put them at the end and the graph will look normal again). Then the last weird thing is if your forward testing has ever gotten to 65536 passes does it freeze at that number? I am also curious what your log file looks like found in user/appdata(hidden folder)/roaming/metaquotes/terminal/yourterminalname/tester/logs My log shows that all the cores connect successfully and are authorized but some of them don't synchronize untill there is a message about passes failing in the test (it says: Tester 17291 forward passes not processed and returned to task queue) My guess is that happens at when it hits 1024 passes then they synchronize and it starts working again. I reference 512 and 1024 but depending on how many passes there are in total I have also seen this happen at 256 and 512. So yea if you could post your log file I would appreciate it. Also if you want, could you tell me if you have an Amd or Intel processor and whether you are testing locally on your computer or on the cloud network. I have an Amd cpu and I am testing locally. So if you are and we find that others are as well, we could tell that that might be causing the problem.

[Stanislav Korotky]

I can confirm the problem with "genetic pass not processed and added to task queue" error. It looks like a bug.

I'm attaching a test EA which should be optimized in math calculations mode. It's based on Joo's articles and test functions.

The only parameter you should change is Parameters. Set it to 2 (default), 4, 6, 8, 10. The actual parameters being optimized is set up by calls to ParameterSetRange. They are arguments of the test functions in a predefined regions, and number of steps per each axis is given in Cycles.

With the values 2 and 4, it works normally (optimization starts and finishes ok).

Larger values lead to indefinite state of the tester - it keeps shuffling passes continuously without any progress.

[tanner gilliland]

I'm starting to think the forward results being wrong might have something to do with the broker or wherever you download the ticks from. I downloaded a new mt5 and got the ticks from mt5 instead of signing in and getting the ticks from my broker (Coinexx). The other bugs still happen but if I can get correct results now, that's amazing.

[tanner gilliland]

Nevermind, It still happens.

[tanner gilliland]

After some experimentation I found out that the bugs happen when the number of inputs possibilities, shown at the bottom of the inputs tab, is large enough to use scientific notation (number e + number). So when the number is 6000000000 the bugs don't happen and when it is 7.5e+20 the bugs do happen. It switches from normal numbers to scientific notation at around 9.2e+18. I have tested it at 922337200577537600 input combinations where the bugs don't happen, and 9.22337315857607e+18 where the bugs do happen.

[Fernando Carreiro]

@tanner gilliland #: After some experimentation I found out that the bugs happen when the number of inputs possibilities, shown at the bottom of the inputs tab, is large enough to use scientific notation (number e + number). So when the number is 6000000000 the bugs don't happen and when it is 7.5e+20 the bugs do happen. It switches from normal numbers to scientific notation at around 9.2e+18. I have tested it at 922337200577537600 input combinations where the bugs don't happen, and 9.22337315857607e+18 where the bugs do happen.

No, I would argue that it has nothing to do with the scientific notation.

Instead, I would think that it has to do with the fact that internally it overflows the maximum value for a 64 bit long integer, of which the maximum value is 9 223 372 036 854 775 807.

[tanner gilliland]

Passes freezing at 65536 has been fixed as of the latest build. Awesome!