Errores, fallos, preguntas - página 479

 
Luego escribe a servicedesk y adjunta el código.
 
sergeev:

A continuación, escriba a Service Desk y adjunte el código.

Sí, es mejor escribir al Service Desk con el código de experto adjunto.

No te preocupes por el código: lo borramos todo después de las pruebas. Nuestra principal y única tarea es encontrar errores.

 

Otra pregunta. Estoy utilizando la función CopyTime. Llama:

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

devuelve sólo un elemento con valor D'2011.08.01' por alguna razón. ¿Dónde está D'2011.07.01' en realidad? ¿Cuál es el truco?

P.D. Array[] es un array dinámico.

 
marketeer:

Otra pregunta. Estoy utilizando la función CopyTime. Llama:

devuelve sólo un elemento con valor D'2011.08.01' por alguna razón. ¿Dónde está D'2011.07.01' en realidad? ¿Cuál es la trampa?

P.D. El array Array[] es dinámico.

Sí, por alguna razón se salta el primer elemento, escribe a 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:

Otra pregunta. Estoy utilizando la función CopyTime.

Ya existe una aplicación similar.

Lo que se está haciendo.

 

Aquí hay otro misterio. No puedo coger el bicho, no sé si es mío o del terminal.

Hay un código trivial que cuenta el número de órdenes colocadas por el Asesor Experto. El contador se almacena en variables globales. Se ve así:

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

Este recuento se utiliza en los comentarios de los pedidos. Como resultado, ocasionalmente observo que el número de la siguiente orden es menor (en algunas unidades) que el número de posiciones que ya están en el mercado. No hay errores en el registro.

¿Tienes alguna idea? ¿Quizás alguien se ha encontrado con una "desaparición" similar de los últimos valores de las variables globales, por ejemplo debido a que el terminal no los guarda al salir bajo ciertas condiciones (bueno, quizás en un caso en el que se pierde la conexión - sólo una versión)?

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

Aquí hay otro rompecabezas. No puedo coger el bicho, no sé si es mío o del terminal.

Prueba algo así. Realmente no lo he hecho de forma global. Pero cuenta bien.

    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:

Prueba algo así. Realmente no lo he hecho de forma global. Pero cuenta bien.

El problema que tengo es que el valor escrito en la variable global se pierde, es decir, no completamente (como cuando se borra por tiempo de espera mensual), sino que se mantiene el antiguo. Por supuesto, puedes recalcular los pedidos, pero mi manera debería funcionar también.
 
papaklass:

A los desarrolladores:

¿Se pretende que si una orden se cierra a su hora de vencimiento, esto no sea seguido de ninguna manera por OnTrade?

PD: El propósito del manejador de eventos de comercio OnTrade no está nada claro. Si un stop loss o take no se capta, si una orden pendiente se cierra por su tiempo de expiración, no se capta. Tenemos que volver a comprobar todo durante la ejecución del algoritmo. Este enfoque causa confusión porque confiamos en el manejador de eventos de comercio pero tenemos que comprobarlo dos veces. Más aún si después de la doble comprobación capturamos los eventos que no son manejados por OnTrade(). ¿Por qué es necesario? Pero ahora podemos jugar al tetris y dibujar todo tipo de tonterías en los gráficos. Los desarrolladores, por favor, lleven la parte de comercio de la plataforma a su conclusión lógica.

No puedo decir nada sobre los pedidos pendientes, aún no he trabajado con ellos.

Por ejemplo, es el manejador de OnTrade el que emite estas líneas en el registro:

2011.08.08 09:03:05 ChTestExp (EURUSD,H1) Posición larga por EURAUD a cerrar 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:

Poner la función Print(__FUNCTION__) en la función OnTrade(). Y cuando lo tengas en tu bitácora

stop loss activado comprar 0.10 AUDUSD 0.89783 sl: 0.89544 tp: 0.90024 [#15 vender 0.10 AUDUSD a 0.89544]
operación #7 vender 0.10 AUDUSD a 0.89544 hecho (basado en la orden #15)
operación realizada [#7 vender 0.10 AUDUSD a 0.89544]
orden realizada vender 0.10 a 0.89544 [#15 vender 0.10 AUDUSD a 0.89544]

¿Puedes comprobar si OnTrade() ha funcionado?

Para mí todo funciona incluso sin su inserción, porque todas las operaciones, sus volúmenes, los beneficios se calculan, todo se suma y se muestra en OnDeinite para cada símbolo por separado. Dado que todos los parámetros sumados (número de operaciones, beneficio) coinciden exactamente con el informe del probador, no tengo motivos para dudar de OnTrade().

Lo único que no se procesa en OnTrade(), son las transacciones de cierre de posición al final de la prueba (con el comentario 'fin de la prueba') y el cierre por un stop out en el probador (comentario 'así ...'), en el modo de prueba, tenemos que procesarlas adicionalmente en OnDeinit. Extracto del registro del probador:

2011.08.09 00:06:43 Núcleo 1 archivo de registro "E:\NProgram 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) generados en 13962 ms (total de barras en el historial 6479, tiempo total 16177 ms)
2011.08.09 00:06:43 El núcleo 1 se ha detenido en el 8% del intervalo de prueba
2011.08.09 00:06:43 Núcleo 1 2011.01.18 10:11:00 Fin de la desinstalación
2011.08.09 00:06:43 Núcleo 1 2011.01.18 10:11:00 Todo Beneficio = -9072,04
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Total de operaciones: 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 Beneficio total EURGBP = -4738,97
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Beneficio de la semana EURGBP = 319.68
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Beneficio total GBPUSD = -3775,86
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Beneficio de la semana GBPUSD = -1798.83
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Beneficio total EURUSD = -557,21
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Beneficio de la semana 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 Núcleo 1 Errores de apertura: 1 Errores de cierre: 0 Errores de modificación: 0 Requerimientos: 1
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 Tiempo de ejecución: 0 min. 14 segundos.
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 ChTestExp Expert Advisor terminó de trabajar en el gráfico EURUSD, período H1
2011.08.09 00:06:43 Núcleo 1 2011.01.18 10:11:00 Ejecución de la desinstalación
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 OnDeinit_UninitReason = Otra razón
2011.08.09 00:06:43 Core 1 OnTester resultado 0
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 orden de compra 1.65 a 1.59804 [#69 comprar 1.65 GBPUSD a 1.59804]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 operación realizada [#68 comprar 1,65 GBPUSD a 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 posición cerrada debido al final de la prueba en 1,59804 [vender 1,65 GBPUSD 1,57341182 tp: 1,57247].
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 orden de compra 0.45 a 0.83931 [#68 comprar 0.45 EURGBP a 0.83931]
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 orden ejecutada [#67 comprar 0.45 EURGBP a 0.83931]
2011.08.09 00:06:43 2011.01.18 10:11:00 operación #67 comprar 0.45 EURGBP a 0.83931 hecho (basado en la orden #68)
2011.08.09 00:06:43 Core 1 2011.01.18 10:11:00 stop de posición activado al 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 Posición larga por EURUSD a cerrar de 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

Del informe del probador:

Resultados
La calidad de la historia: 100%
Bares: 275 Tiki: 888296
Beneficio neto: -9 072.04 Beneficio total: 1 652.29 Pérdida total: -10 724.33
Rentabilidad: 0.15 La recompensa esperada: -533.65
Factor de recuperación: -0.92 Ratio de Sharpe: -0.35

Disminución del balance:
Reducción absoluta del balance: 9 072.04 Máxima disposición en el balance: 10 392.34 (91.80%) Reducción relativa por balance: 91.80% (10 392.34)
Disposición de fondos:
Disminución absoluta de fondos: 9 072.04 Disposición máxima de fondos: 9 852.02 (91.39%) Disposición relativa de los fondos: 91.39% (9 852.02)

Total de intercambios: 17 Operaciones cortas (% de ganadores): 10 (70.00%) Operaciones largas (% de ganancias): 7 (85.71%)
Total de intercambios: 67 Operaciones rentables (% de todas las operaciones): 13 (76.47%) Operaciones con pérdidas (% del total): 4 (23.53%)

La operación más rentable: 263.25 La mayor operación perdedora: -5 036.39

Operación rentable media: 127.10 Operación perdedora media: -2 681.08

Número máximo de victorias continuas (beneficio): 10 (1 320.30) Número máximo de pérdidas continuas (pérdida): 2 (-4 084.59)

Número máximo de ganancias continuas (número de victorias): 1 320.30 (10) Máxima pérdida continua (número de pérdidas): -5 036.39 (1)

Ganancias medias continuas: 4 Pérdidas medias continuas: 1


Como puede ver, las cifras totales, calculadas independientemente, coinciden, significa que todo es correcto. Tomó el ejemplo de la parada a propósito.
Razón de la queja: