Errors, bugs, questions - page 479

New comment
 
Then write to servicedesk and enclose the code.
 
sergeev:

Then write to Service Desk and attach the code.

Yes, it is better to write to Service Desk with the expert code attached.

Don't worry about the code - we erase everything after tests. Our main and only task is to find errors.

 

Another question. I am using the CopyTime function. Call:

CopyTime("EURUSD", PERIOD_MN1, D'2011.06.30', D'2011.08.01', Array)

returns only one element with value D'2011.08.01' for some reason. Where's D'2011.07.01' actually? What's the trick?

P.S. Array[] is a dynamic array.

 
marketeer:

Another question. I am using the CopyTime function. Call:

returns only one element with value D'2011.08.01' for some reason. Where's D'2011.07.01' actually? What's the catch?

P.S. The array Array[] is dynamic.

Yes, for some reason the first element is skipped, write to servicedesk.

datetime Array[];
   CopyTime("EURUSD", PERIOD_MN1, D'2011.06.01', D'2011.08.01', Array); 
   for(int i=0;i<ArraySize(Array);i++)
     {
      Print(i," ",Array[i]);
     }

1 2011.08.01 00:00:00

0 2011.07.01 00:00:00

 
marketeer:

Another question. I am using the CopyTime function.

There is already a similar application.

Figuring it out.

 

Here's another mystery. I can't catch the bug - I don't know if it's mine or the terminal's.

There is a trivial code that counts the number of orders placed by the Expert Advisor. The counter is stored in global variables. It looks like this:

int Count;

int OnInit()
{
  Count = (int)GlobalVariableGet("Count");
  return(0);
}

void OnTick()
{
  // bla-bla-bla
  if(успешно отправлен ордер)
  {
    Count++;
    if(!MQL5InfoInteger(MQL5_TESTING))
    {
      if(GlobalVariableSet("Count", Count) == 0)
      {
        Print("GlobalVariableSet error ", GetLastError());
      }
    }
  }
}

This Count is used in order comments. As a result, I occasionally notice that the next order number is lower (by some units) than the number of positions that are already in the market. There are no errors in the log.

Do you have any idea? Maybe somebody encountered a similar "disappearance" of last values of global variables, for example because of their non-saving by the terminal when exiting under certain conditions (well, maybe in a case where connection is lost - just one version)?

Документация по MQL5: Глобальные переменные терминала / GlobalVariableGet
Документация по MQL5: Глобальные переменные терминала / GlobalVariableGet
  • www.mql5.com
Глобальные переменные терминала / GlobalVariableGet - Документация по MQL5
 
marketeer:

Here is another puzzle. I can't catch the bug - I don't know if it's mine or the terminal's.

Try something like this. I haven't really done it globally. But it counts right.

    int Amount_Orders = 0;

    for(count = 0; count < OrdersTotal(); count++)
       {  
        if(OrderSelect(OrderGetTicket(count))) 
          {
           int tp_ord = (ENUM_ORDER_TYPE)OrderGetInteger(ORDER_TYPE);  
           if(tp_ord == ORDER_TYPE_BUY_STOP  || tp_ord == ORDER_TYPE_SELL_STOP ||
              tp_ord == ORDER_TYPE_BUY_LIMIT || tp_ord == ORDER_TYPE_SELL_LIMIT)
           Amount_Orders++;  
          }
       }
 
tol64:

Try something like this. I haven't really done it globally. But it counts right.

The problem I have is that the value written to the global variable is lost, i.e. not completely (like when deleting by monthly timeout), but the old one remains. You can of course recalculate the orders, but my way should work too.
 
papaklass:

To the developers:

Is it intended that if an order closes by its expiry time, this is in no way tracked by OnTrade?

PS: The purpose of the handler of trade events OnTrade is not clear at all. If a stop loss or take is not caught, if a pending order is closed by its expiry time, it is not caught. We have to double-check everything during the algorithm run. This approach causes confusion because we rely on the trade event handler but have to double-check it. All the more so that after double-checking we catch events that are not handled by OnTrade(). Why is it needed? But now we can play tetris and draw all sorts of nonsense on charts. The developers, please bring the trading part of the platform to its logical conclusion.

I cannot say anything about pending orders, I have not worked with them yet.

For example, it is the OnTrade handler that outputs these lines into the log:

2011.08.08 09:03:05 ChTestExp (EURUSD,H1) Long position by EURAUD to be closed of stop-loss
2011.08.08:09:03:05 ChTestExp (EURUSD,H1) -----------------Deal #5263582 [sl 1.37819]
2011.08.08 09:03:05 ChTestExp (EURUSD,H1) oldDealsTotal=558 newDealsTotal=559
 
papaklass:

Put function Print(__FUNCTION__) in OnTrade() function. And when you have it in your log

stop loss triggered buy 0.10 AUDUSD 0.89783 sl: 0.89544 tp: 0.90024 [#15 sell 0.10 AUDUSD at 0.89544]
deal #7 sell 0.10 AUDUSD at 0.89544 done (based on order #15)
deal performed [#7 sell 0.10 AUDUSD at 0.89544]
order performed sell 0.10 at 0.89544 [#15 sell 0.10 AUDUSD at 0.89544]

Will you check if OnTrade() worked?

For me everything works even without your insertion, because all deals, their volumes, profits are calculated, it all is summed and displayed in OnDeinite for each symbol separately. Since all summed parameters (number of trades, profit) exactly coincide with the tester's report, I have no reason to doubt OnTrade().

The only thing that is not processed in OnTrade(), is transactions of position closing at the end of test (with the 'end of test' comment) and closing by a stop out in the tester (comment 'so ...'), in the test mode, we have to additionally process them in OnDeinit. Excerpt from tester's log:

2011.08.09 00:06:43 Core 1 log file "E:\Program Files\MetaTrader 5\Tester\Agent-127.0.0.1-3000\logs\20110809.log" written
2011.08.09 00:06:43 Core 1 EURUSD,H1: 888296 ticks (275 bars) generated within 13962 ms (total bars in history 6479, total time 16177 ms)
2011.08.09 00:06:43 Core 1 stop out occured on 8% of testing interval
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Deinit end
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 All Profit = -9072.04
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Total trades: 17
.....
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ----------------------------------------
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Total profit EURGBP = -4738.97
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Profit for the week EURGBP = 319.68
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Total GBPUSD profit = -3775.86
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Profit for the week GBPUSD = -1798.83
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Total profit EURUSD = -557.21
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Profit for the week EURUSD = 65.85
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Balance=927.96 Equite=927.96 Profit=0.00 MarginLevel=0.00
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ---------------Report-------------------
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Balance=10000.00 Equite=927.96 Profit=0.00 MarginLevel=0.00
2011.08.09 00:06:43 2011.01.18 10:11:00 Core 1 Opening Errors: 1 Closing Errors: 0 Modifying Errors: 0 Requotes: 1
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Running time: 0 min. 14 sec.
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ChTestExp Expert Advisor finished work on EURUSD chart, H1 period
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Deinit Execution
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 OnDeinit_UninitReason = Another reason
2011.08.09 00:06:43 Core 1 OnTester result 0
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 order buy 1.65 at 1.59804 [#69 buy 1.65 GBPUSD at 1.59804]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 deal performed [#68 buy 1.65 GBPUSD at 1.59804]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 deal #68 buy 1.65 GBPUSD at 1.59804 done (based on order #69)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 position closed due to end of test at 1.59804 [sell 1.65 GBPUSD 1.57341182 tp: 1.57247]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 order buy 0.45 at 0.83931 [#68 buy 0.45 EURGBP at 0.83931]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 order executed [#67 buy 0.45 EURGBP at 0.83931]
2011.08.09 00:06:43 2011.01.18 10:11:00 deal #67 buy 0.45 EURGBP at 0.83931 done (based on order #68)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 position stop triggered at 29.09% [sell 0.45 EURGBP 0.83930333 tp: 0.80463]
2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 Long position by EURUSD to be closed of stop-loss
2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 -----------------Deal #66 sl 1.32900

2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 oldDealsTotal=65 newDealsTotal=66

From the tester report:

Results
Story quality: 100%
Bars: 275 Tiki: 888296
Net profit: -9 072.04 Total profit: 1 652.29 Total loss: -10 724.33
Profitability: 0.15 Expected payoff: -533.65
Recovery factor: -0.92 Sharpe Ratio: -0.35

Balance sheet drawdown:
Absolute balance sheet drawdown: 9 072.04 Maximum drawdown on balance sheet: 10 392.34 (91.80%) Relative drawdown by balance sheet: 91.80% (10 392.34)
Drawdown of funds:
Absolute drawdown in funds: 9 072.04 Maximum drawdown of funds: 9 852.02 (91.39%) Relative drawdown of funds: 91.39% (9 852.02)

Total trades: 17 Short trades (% of winners): 10 (70.00%) Long trades (% wins): 7 (85.71%)
Total trades: 67 Profitable trades (% of all trades): 13 (76.47%) Loss trades (% of all): 4 (23.53%)

Largest profitable trade: 263.25 Largest losing trade: -5 036.39

Average profitable trade: 127.10 Average losing trade: -2 681.08

Maximum number of continuous wins (profit): 10 (1 320.30) Maximum number of continuous losses (loss): 2 (-4 084.59)

Maximum number of continuous profits (number of wins): 1 320.30 (10) Maximum continuous loss (number of losses): -5 036.39 (1)

Average continuous winnings: 4 Average Continuous Losses: 1


As you can see, total figures, independently calculated, coincide, it means everything is correct. Took the stop out example on purpose.
1...472473474475476477478479480481482483484485486...3189
New comment
Reason: