Discussion of article "Night trading during the Asian session: How to stay in profit"

 

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. 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

 
//--- 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.

 
fxsaber:

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
 
ANG3110:

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.

 
Andrey F. Zelinsky:

This is not datetime -- see:

It's just that the author has a problem with variable names

I 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.

 
fxsaber:

In Optimisation mode in MT5 it is not difficult to determine TimeGMT, a single run - you need to think about it.

But what if another person gives the test results? There is no way to determine it.
 
ANG3110:
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.

 
Eugene Myzrov:

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.

 
Dmitriy Zabudskiy: Thanks for the comment. It's a good habit, I do it myself sometimes.... Your example:Honestly, I don't understand, 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. The code size will be reduced, but the speed 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 work some more and somehow change the incoming parameters, then the code can be changed, perhaps simplified.
   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.