Errores, fallos, preguntas - página 2708

Nuevo comentario
 

Sugiero que se añadan detalles a la validación automática de los productos en el mercado. Además de los errores generales notificados por el validador, se solicita encarecidamente el contexto de la prueba realizada y los registros. En particular, no he podido actualizar un indicador desde hace un par de años por el error "el probador tarda demasiado". La primera versión se subió con moderación "humana" y no tuvo ninguna queja. El criterio del autovalidador para emitir este error es totalmente confuso.

He aquí una pregunta concreta: ¿cuántos ticks en qué cantidad de tiempo debe proporcionar el producto en qué hardware para que no aparezca "el probador tarda demasiado"?

El indicador está pensado para el procesamiento de ticks por el algoritmo MapReduce, se utilizan cálculos de enteros, por lo que no hay nada que comprimir, a no ser que se tire el propio algoritmo. Se utilizó el perfilador, se añadió un trotlining para recalcular la matriz de nuevos ticks con un periodo determinado. En vano.

En mi ordenador el año se comprueba en pocos minutos. Lo que realmente ocurre en el autovalidador y por qué se ralentiza es imposible de saber por el momento.

La falta de un apoyo adecuado al producto es un problema tanto para los usuarios como para MQ, ya que afecta a la aplicación.

 

¿Se supone que debe ser así?

class cA
  {
public:
   int               Add(int i1,int i2)
     {
      return i1+i2;
     };
                     cA()
     {
      Print("+++");
     };
                    ~cA()
     {
      Print("---");
     };
  };

void OnStart()
  {
   cA a=cA();
  }

Registro:

2020.04.17 18:39:32.996 test3 (EURUSD,M1)       +++
2020.04.17 18:39:32.996 test3 (EURUSD,M1)       +++
2020.04.17 18:39:32.996 test3 (EURUSD,M1)       ---
2020.04.17 18:39:32.996 test3 (EURUSD,M1)       ---

Doble llamada al constructor y al destructor, como si se creasen y eliminasen dos objetos. Todo está bien cuando se usa nuevo y borrado.

Construye 2380.

 
Aliaksandr Hryshyn:

como si se creasen y eliminasen dos objetos.

Así es.

 
fxsaber:

Lo es.

Y mi objeto se crea en segundo lugar:

class cA
  {
public:
   int               my_i;
   int               Add(int i1,int i2)
     {
      return i1+i2;
     };
                     cA()
     {
      static int i=0;
      my_i=i;
      i++;
      Print("+++");
     };
                    ~cA()
     {
      Print("---");
     };
  };

void OnStart()
  {
   cA a=cA();
   Print(a.my_i);
  }
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       +++
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       +++
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       ---
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       1
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       ---
 
Aliaksandr Hryshyn:

Y mi objeto se crea en segundo lugar:

Primer objeto.

cA a=cA();


Segundo objeto.

cA a=cA();
 

Entonces, así es como debe ser:

cA a;
Print(a.my_i);
 
Stanislav Korotky:

En mi ordenador, un año se comprueba en pocos minutos. Lo que realmente ocurre en el autovalidador y por qué se ralentiza es imposible de saber por el momento.

Un año en pocos minutos es mucho. Casi nadie habría esperado (si fuera un EA).
¿Se dibuja visualmente con normalidad? ¿Es posible entender algo observando al probador?

Añade un enchufe para el mercado: acelerar los cálculos en detrimento de la precisión (si es posible), o dibujar "algo similar" por completo. El producto es claramente específico, y quien lo necesite podrá cambiar el parámetro adecuado.

 
Andrey Khatimlianskii:

Un año en pocos minutos es mucho. Casi nadie habría esperado (si fuera un EA).
¿Está bien dibujado visualmente? ¿Es posible entender algo observando al probador?

Añadir un talón para el mercado: acelerar los cálculos a expensas de la precisión (si es posible), o dibujar "algo similar" por completo. El producto es claramente específico, y quien lo necesite podrá cambiar el parámetro adecuado.

En mi opinión, un año en pocos minutos en modo poético está bien. Antes había un límite de 15-20 minutos en los campeonatos (no recuerdo exactamente). Ya se ha añadido un puesto de trabajo (trotón en tiempo real). Se pueden omitir las garrapatas, pero entonces desaparece el sentido del producto. La especificidad es un concepto relativo: sé que muchos trabajan en modo tic (y todos tienen un complemento con comprobación de precio y/o volumen). Y más importante aún, tener criterios más precisos, además de la retroalimentación del autovalidador (si decimos "tu terminal no funciona" en el foro, nosotros MQ ¿qué pedimos? - Dar los registros y las condiciones para la reproducción; aquí obtenemos un mensaje de que nuestro producto no funciona, pero no hay detalles). Y es más correcto tener en cuenta las particularidades del producto. Al fin y al cabo, el tiempo total de ejecución del producto no es sólo el del código MQL, sino el del propio terminal. Hay llamadas más caras como CopyTicksRange. Estos gastos generales se tienen ahora en cuenta como defectos en el producto MQL.

PS. En el caso de los indicadores parece que no es más crítica la operación por ticks, sino el número de buffers (que son muchos por las peculiaridades de la tarea). Intentaré limitar el número de ellas para el probador (hace que el producto sea más complicado y esté plagado de errores, además de otras banderas impuestas por condiciones externas, como el trote). Esto demuestra una vez más la necesidad de que el autovalidador varíe la puntuación del rendimiento en varios parámetros.

PPS. El probador los carga durante 2 años, y eso también lleva su tiempo.

 
Stanislav Korotky:

PPS. Estoy solicitando garrapatas para el último día, y el probador las carga para 2 años

Por alguna razón este comportamiento es oficial.

Supongo que no deberían generar barras en absoluto para los Asesores Expertos que no utilizan indicadores o barras de dirección, etc.

Por ejemplo, si sólo hay SymbolInfoTick - no generar barras, no almacenar la historia para copyticks.


No está nada clara esta barofilia para una herramienta de algotrading seria como Tester. Pero como hasta los estetas de MO siguen masticando este cactus, es probable que no se entienda.

 

¿Por qué en MQL no puedo llamar al constructor protegido desde mi método de fábrica?

class A1
{
  protected:
    A1(const bool x = false){}
  public:  
    static A1 *creator()
    {
      return new A1(true);
    }
};

void OnStart()
{
  A1 *a = A1::creator();
}

El código da un error de compilación "'A1::A1' - no puede acceder a la función miembro protegida", y especifica la línea donde comienza la descripción de la clase, no donde se llama al constructor (es decir, tengo que buscar manualmente dónde está el problema).

Pero la cuestión es que no debería haber ningún error. C++ compila sin problemas.

1...270127022703270427052706270727082709271027112712271327142715...3187
Nuevo comentario
Razón de la queja: