MT version archive. - page 4

New comment
 
Roman:

In this context, can't we do the check?

Unfortunately, this check did not yield anything...

 
Roman:

By giving an example with IsStopped(), I was just trying to answer the first part.
Sometimes it is necessary to complete processing of an event beforehand, and sometimes it is urgent like in your case.
Read the description of this function IsStopped() in documentation, maybe it will lead to some ideas.
But it seems to you it's from another direction. If so, sorry for a possible guess.
But as they say in possible suggestions, and solves the problem.
Definite solution will not tell anyone, because no one knows all the logic of his code, and probably will not delve into it.

Roman, once again, you're not quoting all the way through. And you have highlighted it among all the highlighted ones.

Well, okay, let's say a forced shutdown is started. And I need to have this termination event executed until the end and the complexity of calculations exceeds 3 seconds. And how can I prevent termination of the program and let it run to the end? That's exactly the problem. The conversation was not about how to terminate, but how to prevent an incorrectly invoked termination. Or not to prevent, but to postpone until a certain point, in particular until the event processing is complete.

 
Сергей Таболин:

Here's a check on your option. It ended up with a message like this:

It's a dead end...

So the suggested option is 

bool                 tester_stop = false;                 // флаг проверки выхода по TesterStop
.......
void OnTick()
{
//--- пропустить бесполезные проходы оптимизации
   if(!check_init && (MQLInfoInteger(MQL_OPTIMIZATION) || MQLInfoInteger(MQL_TESTER)))
   {
      if(недопустимый параметр)          tester_stop = TesterStop();
........
}
double OnTester()
{
   if(tester_stop) return(-99999999999.99);

will be worked out exactly the same way. And you will again get a "deadlock". But the deadlock is not in mql, but in your mind. This is no way to do programming. Before you expect anything from the code, imagine yourself in the place of an idiot and walk blindly, as a computer does, through the whole code several times. Make sure where execution must be passed in a particular case. What parameters must be received in a particular case. Then start the execution and check if we get what we expect. If no, then we must find out where we get what we see during the debugging process.

It cannot be otherwise. And it is absolutely impossible to debug the code fragments.

 
Alexey Viktorov:

Roman, once again, you're not quoting all the way through. And you've highlighted amongst all the highlighted.

Well, okay, let's say a forced termination is triggered. And I need the event in which this termination is triggered to be executed until the end and the complexity of calculations exceeds 3 seconds. And how can I prevent program termination and let it run to the end? That's exactly the problem. The conversation was not about how to terminate, but how to prevent an incorrectly invoked termination. Or not to prevent, but to delay until a certain point, in particular until the event processing is complete.

We have to wait for the calculation to complete.

Unfortunately, mql doesn't contain functions like await.
We can try to experiment with Sleep(), but slip is not an explicit sign of termination, so it's not very suitable.
Try to create another condition, if(the calculation is executed), then we will already start a forced termination.

 
Alexey Viktorov:

So the option I'm proposing

will be worked out in exactly the same way. And once again you will get a "deadlock". But the deadlock is not in mql, but in your mind. You cannot go in for programming like that. Before you expect anything from the code, imagine yourself in the place of an idiot and walk blindly, as a computer does, through the whole code several times. Make sure where execution must be passed in a particular case. Which parameters should be received in a particular case. Then start the execution and check if we get what we expect. If no, then we must find out where we get what we see during the debugging process.

It cannot be otherwise. But you cannot debug the code fragment by fragments.

Well, that's the point is that everything was working before the update and now I just don't know what to do.

Besides, all the code is open in principle.

Moreover, I wanted to open a thread to discuss improvement of my version OnTester() and here it is...

As it turned out, the problem is not in it but in changed TesterStop() execution. It actually has no direct connection with OnTester(), but it spoiled my mood...

I'll try something else now...

 
Сергей Таболин:

That's the thing, before the update everything was working, but now I just don't know what to do.

Besides, in principle, all the code is open.

Moreover, I already wanted to open a thread to discuss improvement of my version OnTester() and here it is...

As it turned out, the problem is not in it but in changed TesterStop() execution. It actually has no direct connection with OnTester(), but it spoiled my mood...

I'll try something else now...

You've given a link to previous builds. Replace the files and check them. Then you can tell everyone which build works now. If it does not work, it means that the parameters that did not lead to this part of the code where the problems appeared now were simply the same.

 
Alexey Viktorov:

So gave you a link to previous builds. Replace the files and check. Then you can tell everybody which build works now. If it does not work, it means that the parameters that do not lead to this part of the code, where the problems appeared now, were simply the same.

That's how I tried it. Put up the 2007 build and there all these problems are gone. I specifically looked through the whole log after optimisation. I found 4 (only 4 !) errors of division by zero. Those were the ones that occurred when there were no trades. Of course, this needed to be fixed, but it had no effect on the overall optimization result! But the new build has caused an alarming amount of errors and made optimization impossible.

Now, regarding@Roman' s tip.

Thank you, it was a good one. But in my case, it appeared to be useless for TesterStop() because TesterStop() requires that the test must already have passed some unknown percentage. And there is not a word about it in the documentation.

But it worked well with ExsprtRemove(). It does not matter for this function how many tests passed there. But we had to wrap the entire working code into the if

   if(!IsStopped())
   {
      тут рабочий код
   }

Well, I managed to fix the code with crutches. Thanks again.

P.S. Actually I had to make a crutch for another crutch. Funny ))))

 
Сергей Таболин:

P.S. Actually had to make a crutch for the other crutch. That's funny ))))

I do not believe that there are no options. If you like programming crutches to crutches, I have no right to prevent. Slava replied on this subject.

Forum on trading, automated trading systems and strategy testing

Bugs, bugs, questions

Slava, 2019.06.16 14:04

Stopping the Expert Advisor immediately means memory corruption. After an immediate stop of the Expert Advisor, there may be unreleased memory blocks. Therefore, immediate stop of the Expert Advisor is only used when the client terminal or the tester agent is terminated and only if the Expert Advisor does not process the stop flag and continues execution.

TesterStop gives the command to terminate testing. It means that after the current handler OnInit, OnTick, OnTimer, OnChartEvent is finished, no more events of the tester will be handled, as the processing cycle is finished. Instead OnTester and OnDeinit are called.

Perhaps, you have used a bug in the previous build. Now this bug has been fixed and we have to look for a proper solution.
 
Сергей Таболин:

That's how I tried it. Put up the 2007 build and there all these problems are gone. I specifically looked through the whole log after optimisation. I found 4 (only 4 !) errors of division by zero. Those were the ones that occurred when there were no trades. Of course, this needed to be fixed, but it had no effect on the overall optimization result! But the new build has caused an alarming amount of errors and made optimization impossible.

Now, regarding@Roman' s tip.

Thank you, it was a good one. But in my case, it appeared to be useless for TesterStop() because TesterStop() requires that the test must already have passed some unknown percentage. And there is not a word about it in the documentation.

But it worked well with ExsprtRemove(). It does not matter for this function how many tests passed there. But we had to wrap the entire working code into the if

Well, I managed to fix the code with crutches. Thanks again.

P.S. Actually I had to make a crutch for another crutch. Funny ))))

This is not a crutch, but a recommended practice from the developers.
I found this function in the description of the while loop

while(!IsStopped())
{

}

That is why I had an idea: if this function checksthe fact of forced program termination, why not use it for TesterStop().
It is a pity it does not work for TesterStop(), we will know about it now.
But it is fair to ask the developers ifIsStopped() function must work for TesterStop() function?
Maybe it is a bug?

But the main thing is the solution to the problem.

 
Alexey Viktorov:

I don't believe there are no options. If you like programming crutches to crutches, I have no right to interfere. Slava replied on this subject

Perhaps, you have used a slip-up the developers made in the previous build. Now this bug is fixed and we have to look for a proper solution.

I understand everything, and I don't need crutches. And I had to look for a crutch here, read it for what.

Perhaps. But I don't recall someone complaining about it.

1234567
New comment
Reason: