Errors, bugs, questions - page 891

[A100]

It is clear that zeroing was done for compatibility, but it is not clear why when unused enum = WRONG_VALUE is initialized correctly , it does not work correctly. This approach lacks portability and significantly increases the probability of hidden errors.

[Yedelkin]

A100: it's unclear why when unused enum = WRONG_VALUE is initialized correctly, it doesn't work correctly.

Remember this rule?

Rule: If a named constant - member of an enumeration is not explicitly assigned a specific value, its value will be generated automatically. If it is the first member of the enumeration, the value 0 will be assigned. For all subsequent members, values will be calculated based on the value of the previous member by adding one.

Most likely, checking for the correctness of the query fields assumes that the value of an enumeration member cannot be negative. The possibility of assigning WRONG_VALUE to an enumeration member is not taken into account.

[A100]

Yedelkin:

However, the possibility of assigning WRONG_VALUE to an enumeration member is not taken into account.

I think this is exactly the error here. If a concrete enum is not used, it is logical that its value will be WRONG_VALUE instead of, for example, ORDER_TYPE_BUY that actually = 0.

and most importantly - nothing prevents you from changing the OrderCheck() and OrderSend() logic while maintaining compatibility

[Yedelkin]

A100: I think this is exactly the error here. If a concrete enum is not used, it is logical that its value will be WRONG_VALUE instead of ORDER_TYPE_BUY that actually = 0.

and most importantly, nothing prevents you from changing the logic of OrderCheck() and OrderSend() while maintaining compatibility

There is a way to understand the developers' opinion - write to Service Desk about the error.

[Lev Ilyukov]

I've discovered a strange "bug".

I am using this code in my EA:

void OnTradeTransaction(const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result)
  {
   if(trans.type == TRADE_TRANSACTION_DEAL_ADD)
    {
     if(trans.symbol == "EURUSD") EURUSD_K = 1;
    }    
  }

A single run in the tester passes without problems, but as soon as I choose parameters with full search, the tester starts working ten or ten times slower. I don't understand why the speed is adequate during one run and falls noticeably during optimization. Moreover, it drops geometrically. You can see by the percentage that everything is OK in the beginning but towards the end the speed keeps slipping slower and slower. I searched for problems in my code and looked for loops or something, but failed to find them. After that I replaced above mentioned code with my own algorithm and oh my god! Optimization now runs at a normal, uniform speed. This leads me to the conclusion that the issue is within MQL5, somewhere in the body of the OnTradeTransaction function. I will ask the developers to pay attention to that.

p.s. I cannot post the Expert Advisor code. Try to use the above code in any of your EAs and look at the speed of optimization in OHLC M5 for the period from 2000 to today.

[Konstantin Chernov]

lordlev:

I have discovered a strange "bug".

I am using this code in my EA:

A single run in the tester passes without problems, but as soon as I choose parameters with full search, the tester starts working ten or ten times slower. I don't understand why the speed is adequate during one run and falls noticeably during optimization. It is falling geometrically. You can see by the percentage that everything is OK in the beginning but towards the end the speed keeps slipping slower and slower. I searched for problems in my code and looked for loops or something, but failed to find them. After that I replaced above mentioned code with my own algorithm and oh my god! Optimization now runs at a normal, uniform speed. This leads me to the conclusion that the issue is within MQL5, somewhere in the body of the OnTradeTransaction function. I will ask the developers to pay attention to that.

p.s. I cannot post the Expert Advisor code. Try to use the above code in any of your EAs and look at the speed of optimization in OHLC M5 for the period from 2000 to today.

With different parameters the Expert Advisor may work for different time

[Lev Ilyukov]

Konstantin83:
For different parameters, the EA may run for different lengths of time

In this case, the problem is not with the Expert Advisor or the parameters. The problem is in MQL5 itself.

[A100]

lordlev:

After replacing the above code with your algorithm

I.e. they gave up using OnTradeTransaction()? - then it is logical that the speed has increased - it is called on every occasion

[Lev Ilyukov]

A100:
I.e. they gave up using OnTradeTransaction() ? - then it is logical that the speed has increased - it is called on every occasion

It's natural to refuse to use it. It's clear that it is called at any occasion. It's just unclear why the speed is adequate during a single run, while it suddenly drops during optimization. It has nothing to do with the parameters themselves, as another friend wrote above, I checked it thoroughly ten times. This leads me to the conclusion that the developers made a mistake somewhere.

[TheXpert]

lordlev:

What's stopping you from doing a minimal test case and reporting back to the service desk?