Why would the number of passes in the strategy tester determine whether a bug happens or not.

[tanner gilliland]

I am trying to figure out why only me and a couple other people experience certain bugs when doing forward tests (https://www.mql5.com/en/forum/454524). I believe the bugs might be hardware related. 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 where the bugs don't happen, and 9.22337315857607e+18 where the bugs do happen. Does anyone know why this might be the case or why most people don't experience these bugs but some do? My best guess right now is that it happens when you have an amd ryzen processor like me but people have intel processors and are fine. (I don't know what I'm talking about so who knows why it happens). If anyone who has a ryzen 7000 processor, or even an intel one, could try out the ea to see if they experience the bugs I would appreciate it. I uploaded the ea and the inputs file. The settings are: EURUSD, 1M, the last month, 1/4 forward, zero latency, every tick, 10000, fast genetic with complete criterion max. (I don't think any of the setting or inputs matter too much, I have tried it with various settings and inputs) The bugs to look for: during forward testing some or most of your cores are just "authorized" and aren't doing anything. When it gets closer to 256 and 512 (or 512 and 1024 if there are enough passes) the passes start to slow down and do not match the passes shown being completed by the agents/cores. During the passes from 256 to 512 (or 512 to 1024) it will do passes that should be at the end of the test (it will look like you can take the passes from 256 to 512, put them at the end, and the graph will look correct). If you had a forward optimization that has more than 65536 passes, at 65536 passes the tester will fail every pass, returning them to the queue. It will keep failing indefinitely. If you try to stop it or close the program it will freeze up. Anyway I would appreciate any thoughts on the matter, Thanks.

[Ivan3z]

This is a supposition!!

But the computers can not handle very large integers numbers...

This is the integer number Windows can handle today in 2024 -->  18446744073709551615

https://learn.microsoft.com/es-es/cpp/cpp/integer-limits?view=msvc-170

if the number is bigger it cause a "stack overflow".

The the data you obtain using biggers numbers are not reliable...

When you see a change from an integer to a float like this (922337200577537600 --> 9.22337315857607e+18) probably that is the "stack overflow"

because as far i kwow is not posible change the data type at run time

in fact!!

LLONG_MAX

(is  long long)

9223372036854775807

It is Very similar to your number!!

Best regards!!