//--- input parameters input int order_time=0; // Order opening time
The trouble with both testers is that datetime cannot be optimised. Hence this forced ugliness.
We should have solved this problem long ago.
ZY OnTesterInit can help with datetime, but not everyone can.
It would be good if in the terminal it would be possible to know the broker's shift time at least relative to GMT. More precisely, it would be written in the terminal for each broker. And in the test results. But tests are given - what time shift is there? I don't know.
Request TimeGMT() is good, but it is not enough. And it doesn't give anything to consider the test. We need exactly the time of broker's shift relative to GMT.
The trouble with both testers is that datetime cannot be optimised. Hence this forced ugliness.
Something should have been done about this a long time ago.
It is not datetime that is meant here -- see:
if(time_now_str.hour==order_time && work==true && work_day==true)It's just that the author has a problem with variable names
It would be good if in the terminal it would be possible to know the broker's shift time at least relative to GMT. More precisely, it would be written in the terminal for each broker. And in the test results. But tests are given - what time shift is there? I don't know.
Request TimeGMT() is good, but it is not enough. And it doesn't give anything to consider the test. It is the broker's time shift relative to GMT that is needed.
It is easy to determine TimeGMT in the Optimisation mode in MT5, a single run - you should think about it.
This is not datetime -- see:
It's just that the author has a problem with variable namesI repent, I read the article only up to the quoted line. But the datetime problem does exist. Time should be optimised not only through MQL, but also, humanly speaking, through GUI.
In Optimisation mode in MT5 it is not difficult to determine TimeGMT, a single run - you need to think about it.
What if other people are given the test results? There's no way to tell.
Yeah, there's no mention of that in the report. That's why custom reports are powerful. Especially in MT5.
Maybe instead of
//+------------------------------------------------------------------+ //| Expert tick function| //+------------------------------------------------------------------+ void OnTick() { //--- time_now_var=TimeCurrent(time_now_str);// current time switch(time_now_str.day_of_week) { case 1: if(mon==false){work_day=false;} else {work_day=true;} break; case 2: if(tue==false){work_day=false;} else {work_day=true;} break; case 3: if(wen==false){work_day=false;} else {work_day=true;} break; case 4: if(thu==false){work_day=false;} else {work_day=true;} break; case 5: if(fri==false){work_day=false;} else {work_day=true;} break; }
use a simpler one
//+------------------------------------------------------------------+ //| Expert tick function| //+------------------------------------------------------------------+ void OnTick() { time_now_var=TimeCurrent(time_now_str);// current time switch(time_now_str.day_of_week) { case 1: work_day=mon; break; case 2: work_day=tue; break; case 3: work_day=wen; break; case 4: work_day=thu; break; case 5: work_day=fri; break; } ...
As they say, it's nothing personal, just a stupid habit - I can't pass by when I see some inefficient code.
I didn't look further into the code.
Maybe instead of
use a simpler one
As they say, it's nothing personal, just a stupid habit - I can't pass by when I see some inefficient code.
I didn't look further into the code.
Thank you for your comment. The habit is a good one, I do it myself sometimes too.....
Your example:
//+------------------------------------------------------------------+ //| Expert tick function| //+------------------------------------------------------------------+ void OnTick() { time_now_var=TimeCurrent(time_now_str);// current time switch(time_now_str.day_of_week) { case 1: work_day=mon; break; case 2: work_day=tue; break; case 3: work_day=wen; break; case 4: work_day=thu; break; case 5: work_day=fri; break; } ...
Frankly speaking, I don't understand it, it needs to be supplemented... Because in the incoming variables in the Expert Advisor, the days of the week in which you need to work are marked as "true", and if you do not need to work on that day, then "false".
And the variable "work_day" sends the answer as "true" or "false". In your example, the variable becomes of "string" type, so you will have to make a comparison again.
And so, I am for code optimisation, although in this EA, it was not a priority.
This particular code can be optimised:
//+------------------------------------------------------------------+ //| Expert tick function| //+------------------------------------------------------------------+ void OnTick() { //--- time_now_var=TimeCurrent(time_now_str);// current time work_day=true; switch(time_now_str.day_of_week) { case 1: if(mon==false){work_day=false;} break; case 2: if(tue==false){work_day=false;} break; case 3: if(wen==false){work_day=false;} break; case 4: if(thu==false){work_day=false;} break; case 5: if(fri==false){work_day=false;} break; }
The code size will be reduced, but the speed of work will not...
Perhaps you can implement a loop in the function, then the size may be smaller, but the processing speed will be longer.
You can also work and change the incoming parameters, then you can change the code, perhaps simplify it.
work_day=false; switch(time_now_str.day_of_week) { case 1: if (mon) work_day=true; break; case 2: if (tue) work_day=true; break; case 3: if (wen) work_day=true; break; case 4: if (thu) work_day=true; break; case 5: if (fri) work_day=true; break; }
You could offer such a code as well. But by removing the "else" operators, you have simplified the source code only half. The optimal variant will be obtained if you remove "if" operators as well, leaving only 5 assignment operators. This will be the optimal variant that has been suggested.
switch(time_now_str.day_of_week) { case 1: work_day=mon; break; case 2: work_day=tue; break; case 3: work_day=wen; break; case 4: work_day=thu; break; case 5: work_day=fri; break; default: work_day=false; // в субботу и воскресенье не торгуем... }
But I don't understand at all about the variable that becomes of the "string" type.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Night trading during the Asian session: How to stay profitable has been published:
The article deals with the concept of night trading, as well as trading strategies and their implementation in MQL5. We perform tests and make appropriate conclusions.
Let's take the popular EURUSD pair. During the Asian session, its volatility usually decreases and it starts moving in flat. A roll-back at this stage is often insignificant and may resemble a horizontal movement.
Fig. 2. Flat movement on EURUSD during the Asian session
Fig. 2 yellow rectangles indicate EURUSD movement on H1 during the Asian session. The first one (on the left) demonstrates a small intra-channel oscillation. At the beginning of the session, the price follows the previously created trend, then a small correction occurs (in the middle of the session) only to turn into a sharp roll-back in the end. The second rectangle shows a slow upward movement, which in this case repeats the movement at the end of the day. The third rectangle demonstrates a slight change. Unlike the previous sessions, the initial night time movement corrects the daily trend.
Author: Dmitriy Zabudskiy