Erros, bugs, perguntas - página 479

 
Em seguida, escrever para Servicedesk e anexar o código.
 
sergeev:

Em seguida, escrever ao Service Desk e anexar o código.

Sim, é melhor escrever para o Service Desk com o código de perito em anexo.

Não se preocupe com o código - apagamos tudo após os testes. A nossa tarefa principal e única é encontrar erros.

 

Outra questão. Estou a utilizar a função CopyTime. Chamada:

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

devolve apenas um elemento com o valor D'2011.08.01' por alguma razão. Onde está o D'2011.07.01' na realidade? Qual é o truque?

P.S. Array[] é uma matriz dinâmica.

 
marketeer:

Outra questão. Estou a utilizar a função CopyTime. Chamada:

devolve apenas um elemento com o valor D'2011.08.01' por alguma razão. Onde está o D'2011.07.01' na realidade? Qual é o senão?

P.S. O array Array[] é dinâmico.

Sim, por alguma razão o primeiro elemento é ignorado, escreva para 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:

Outra questão. Estou a utilizar a função CopyTime.

Já existe uma aplicação semelhante.

Descobrindo-o.

 

Aqui está outro mistério. Não consigo apanhar o insecto - não sei se é meu ou do terminal.

Existe um código trivial que conta o número de encomendas feitas pelo Conselheiro Especialista. O contador é armazenado em variáveis globais. É o que parece:

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());
      }
    }
  }
}

Esta Contagem é utilizada para comentários de ordem. Como resultado, ocasionalmente noto que o número de ordem seguinte é inferior (por algumas unidades) ao número de posições que já se encontram no mercado. Não há erros no registo.

Tem alguma ideia? Talvez alguém tenha encontrado um "desaparecimento" semelhante dos últimos valores das variáveis globais, por exemplo devido à sua não poupança pelo terminal ao sair sob certas condições (bem, talvez num caso em que a ligação se perde - apenas uma versão)?

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

Aqui está outro puzzle. Não consigo apanhar o insecto - não sei se é meu ou do terminal.

Tente algo como isto. Não o tenho feito realmente a nível global. Mas conta bem.

    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:

Tente algo como isto. Não o tenho feito realmente a nível global. Mas conta bem.

O problema que tenho é que o valor escrito à variável global é perdido, ou seja, não completamente (como quando se apaga por timeout mensal), mas o antigo permanece. É claro que pode recalcular as ordens, mas a minha maneira também deve funcionar.
 
papaklass:

Aos promotores:

Pretende-se que se uma encomenda for encerrada no seu prazo de validade, isso não seja de forma alguma rastreado pela OnTrade?

PS: A finalidade do manipulador de eventos comerciais OnTrade não é de todo clara. Se uma paragem de perda ou tomada não for apanhada, se uma ordem pendente for encerrada até ao seu prazo de validade, não é apanhada. Temos de verificar tudo de novo durante a execução do algoritmo. Esta abordagem causa confusão porque dependemos do manipulador de eventos comerciais, mas temos de a verificar duas vezes. Tanto mais que, após uma dupla verificação, apanhamos eventos que não são tratados pela OnTrade(). Porque é necessário? Mas agora podemos jogar tetris e desenhar todo o tipo de disparates nas cartas. Os criadores, por favor levem a parte comercial da plataforma à sua conclusão lógica.

Não posso dizer nada sobre ordens pendentes, ainda não trabalhei com elas.

Por exemplo, é o manipulador da OnTrade que produz estas linhas para o diário de bordo:

2011.08.08 09:03:05 ChTestExp (EURUSD,H1) Posição longa por EURAUD a ser fechada de 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:

Coloque a função Print(__FUNCTION__) na função OnTrade(). E quando o tiver no seu diário de bordo

stop loss triggered buy 0,10 AUDUSD 0,89783 sl: 0,89544 tp: 0,90024 [#15 vende 0,10 AUDUSD a 0,89544]
negócio #7 vender 0,10 AUDUSD a 0,89544 feito (com base no pedido #15)
negócio realizado [#7 vender 0,10 AUDUSD a 0,89544]
ordem executada vender 0,10 a 0,89544 [#15 vender 0,10 AUDUSD a 0,89544]

Vai verificar se a OnTrade() funcionou?

Para mim tudo funciona mesmo sem a sua inserção, porque todos os negócios, os seus volumes, os seus lucros são calculados, tudo é somado e exibido em OnDeinite para cada símbolo separadamente. Uma vez que todos os parâmetros somados (número de negócios, lucro) coincidem exactamente com o relatório do testador, não tenho razões para duvidar da OnTrade().

A única coisa que não é processada no OnTrade(), são transacções de fecho de posição no final do teste (com o comentário 'fim do teste') e fecho por uma paragem no testador (comentário 'so ...'), no modo teste, temos de as processar adicionalmente no OnDeinit. Excerto do diário de bordo do testador:

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" escrito
2011.08.09 00:06:43 Core 1 EURUSD,H1: 888296 ticks (275 barras) gerados dentro de 13962 ms (total de barras na história 6479, tempo total 16177 ms)
2011.08.09 00:06:43 O Core 1 stop out ocorreu em 8% do intervalo de testes
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Deinit end
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Todos os lucros = -9072.04
2011.08.09 00:06:06:43 Núcleo 1 2011.01.18 10:11:00 Total de comércios: 17
.....
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 ----------------------------------------
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Lucro total EURGBP = -4738.97
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Lucro para a semana EURGBP = 319.68
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Lucro total GBPUSD = -3775.86
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Lucro para a semana GBPUSD = -1798.83
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Lucro total EURUSD = -557.21
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Lucro para a semana EURUSD = 65.85
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Saldo=927.96 Equite=927.96 Lucro=0.00 MarginLevel=0.00
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 ---------------Report-------------------
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Saldo=10000.00 Equite=927.96 Lucro=0.00 MarginLevel=0.00
2011.08.09 00:06:43 2011.01.18 10:11:00 Core 1 Erros de Abertura: 1 Erros de Fecho: 0 Erros de Modificação: 0 Exigências: 1
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Tempo de funcionamento: 0 min. 14 seg.
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 ChTestExp Expert Advisor terminou o trabalho no gráfico EURUSD, período H1
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 Deinit Execution
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 OnDeinit_UninitReason = Outro motivo
2011.08.09 00:06:43 Resultado do teste de núcleo 1 0
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 compra 1.65 a 1.59804 [#69 compra 1.65 GBPUSD a 1.59804]
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 negócio realizado [#68 comprar 1.65 GBPUSD a 1.59804]
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 negócio #68 comprar 1,65 GBPUSD a 1,59804 feito (com base na encomenda #69)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 posição fechada devido ao fim do teste a 1.59804 [vender 1.65 GBPUSD 1.57341182 tp: 1.57247]
2011.08.09 00:06:06:43 Core 1 2011.01.18 10:11:00 compra 0,45 a 0,83931 [#68 compra 0,45 EURGBP a 0,83931]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ordem executada [#67 comprar 0,45 EURGBP a 0,83931]
2011.08.09 00:06:43 2011.01.18 10:11:00 negócio #67 comprar 0,45 EURGBP a 0,83931 feito (com base na encomenda #68)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 paragem de posição activada a 29.09% [vender 0.45 EURGBP 0.83930333 tp: 0.80463]
2011.08.09 00:06:43 Core 1 2011.01.17 14:39:39 Posição longa por EURUSD a ser fechada de stop-loss
2011.08.09 00:06:06:43 Core 1 2011.01.17 14:39:39 -----------------Deal #66 sl 1.32900

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

A partir do relatório do provador:

Resultados
Qualidade da história: 100%
Bares: 275 Tiki: 888296
Lucro líquido: -9 072.04 Lucro total: 1 652.29 Perda total: -10 724.33
Rentabilidade: 0.15 Pagamento previsto: -533.65
Factor de recuperação: -0.92 Rácio Sharpe: -0.35

Levantamento de balanços:
Levantamento absoluto do balanço: 9 072.04 Máximo levantamento de crédito no balanço: 10 392.34 (91.80%) Levantamento relativo por balanço: 91.80% (10 392.34)
Levantamento de fundos:
Levantamento absoluto de fundos: 9 072.04 Máximo levantamento de fundos: 9 852.02 (91.39%) Levantamento relativo de fundos: 91.39% (9 852.02)

Total de comércios: 17 Ofícios curtos (% de vencedores): 10 (70.00%) Comércios longos (% ganha): 7 (85.71%)
Total de comércios: 67 Ofícios rentáveis (% de todos os ofícios): 13 (76.47%) Perdas comerciais (% de todas): 4 (23.53%)

O maior comércio lucrativo: 263.25 A maior perda de comércio: -5 036.39

Comércio lucrativo médio: 127.10 Média das perdas comerciais: -2 681.08

Número máximo de vitórias contínuas (lucro): 10 (1 320.30) Número máximo de perdas contínuas (perda): 2 (-4 084.59)

Número máximo de lucros contínuos (número de vitórias): 1 320.30 (10) Perda máxima contínua (número de perdas): -5 036.39 (1)

Ganhos médios contínuos: 4 Média de Perdas Contínuas: 1


Como pode ver, os números totais, calculados independentemente, coincidem, o que significa que tudo está correcto. Tomou o exemplo de paragem de propósito.