Error en MQL5 al trabajar con el acceso a series temporales iClose/iOpen, etc. - página 9

[Unicornis]

Vitaly Muzichenko:

Entonces, ¿será posible tener un indicador muy rápido con dicha construcción?

Lo más probable es que no se llame a OnCalculate en cada tic, sino después de un paquete de tics.

Si es así, ¡es una gran noticia!

[fxsaber]

Renat Fatkhullin:

Tenemos una idea para los indicadores, que no contienen la bandera #property tester_everytick_calculate, para incluir el modo de cálculo en base a la aceptación del paquete de ticks, en lugar de en cada tick.

Esto resolverá radicalmente el problema de los indicadores tardíos, preservando la posibilidad de garantizar el procesamiento de cada tick para algunos indicadores.

Propongo otra solución.

SymbolInfoTick

Devuelve los precios actuales de un símbolo especificado en una variable de tipo MqlTick.

bool  SymbolInfoTick( 
   string    symbol,     // символ 
   MqlTick&  tick        // ссылка на структуру
   bool      IndicatorMode = true; // индикаторный или реальный (текущий) тик
   );

Parámetros

símbolo

[Nombre del símbolo.

garrapata .

[out] Una estructura de referencia de tipoMqlTick, en la que se colocan los precios actuales y la última hora de actualización de los precios.

IndicatorMode

[out] true - en los indicadores devuelve el tick que desencadenó el NewCalculate actual, false - tick actual (tiempo real) de un símbolo.

Valor devuelto

Devuelve true si tiene éxito, en caso contrario false.

Entonces en OnCalculate bastará con escribir sólo esta construcción

// Возвращает true, если текущий и индикаторный тики совпадают
bool IsRealTick( void )
{
  MqlTick Tick1, Tick2;
  
  return(SymbolInfoTick(_Symbol, Tick1) && SymbolInfoTick(_Symbol, Tick2, false) && (Tick1.time_msc == Time2.time_msc));
}

int OnCalculate( ... )
{
  if (prev_calculated && !IsRealTick())
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  return(rates_total);
}

Esta solución sería más flexible y cómoda de utilizar y aplicar.

SZY Sería mejor tener la numeración de los ticks, con posibilidad de obtener el número de tick actual y del indicador. Pero esta variante es más difícil para los desarrolladores. Por lo tanto, probablemente no sea necesario.

[fxsaber]

fxsaber:

Sugiero otra solución.

Si los desarrolladores no hacen nada (lo cual es una muy buena opción, por cierto), todavía es posible saltarse todos los frenos de esta manera

int OnCalculate( ... )
{
  static ulong MinTimeMsc = 0
  const ulong StartTime = GetMicrosecondCount();
  
  MqlTick Tick;
  const bool Res = prev_calculated && SymbolInfoTick(_Symbol, Tick);
  
  if (Res && (Tick.timeMsc < MinTimeMsc))
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  if (Res)
    MinTimeMsc = Tick.time_msc + (GetMicrosecondCount - StartTime) / 2000;
  
  return(rates_total);
}

[Unicornis]

fxsaber:

Si los desarrolladores no hacen nada (que es una muy buena opción, por cierto), es posible saltarse todos los frenos ahora de esta manera

Bueno, no necesitamos ticks en medio de una barra, se saltan forzosamente de todos modos. Esperemos a la implementación por parte de mql.

[fxsaber]

Unicornis:

Bueno, no necesitamos ticks en medio de una barra, se saltan forzosamente de todos modos. Esperemos a la implementación de mql.

Sinceramente, no lo entiendo, ¿qué ha impedido a los afectados escribir ellos mismos una solución a su problema?

¿Y por qué los desarrolladores deberían cambiar algo aquí?

La solución puede implementarse como un archivo mqh y conectarse a cualquier indicador, como se implementa en Init_Sync. Pero requiere un montón de código que no es muy obvio. Y aquí sólo hay unas pocas líneas.

[Farkhat Guzairov]

Renat Fatkhullin:

La actualización congelada del marco temporal invisible de otra persona después de la comunicación de reconexión fue resuelta y arreglada. El motivo era el estado incorrecto de la caché tras la reconexión.

La versión beta 1946 está disponible a través de Ayuda -> Comprobar actualizaciones del escritorio -> Última versión beta.

Rinat, 3 días de pruebas sin problemas, ¡gracias!

[Unicornis]

fxsaber:

Sinceramente, no entiendo qué ha impedido a los afectados escribir ellos mismos una solución a su problema.

¿Y por qué deberían los desarrolladores cambiar algo aquí?

Los que sufren no pueden cambiar el número de ticks entrantes en el indicador de ninguna manera, los omiten en el indicador hasta una nueva barra, si el indicador cuenta durante mucho tiempo, los ticks se omiten de todos modos. De alguna manera tenemos que adaptarnos a la realidad.

Si para un símbolo el valor máximo es de ~800 ticks por minuto, para el sintético de varios símbolos ya son 2300 ticks por minuto. La apertura de un sintético y un símbolo de él alcanza un máximo de ~3000 ticks por minuto. Añade otro marco temporal del mismo sintético y el mismo símbolo, y obtenemos... Ok, las pantallas de Elder eran tres, tenemos ~9000 ticks por minuto o 150 ticks por segundo. Rinat ya ha escrito sobre los problemas de rendimiento. ¿Por qué pasar 150 ticks por segundo a través de un indicador multisímbolo-mtf cuando necesitas 1-n tick por minuto para todos los símbolos tf? Asimismo, las ventajas de alojar mql incluyen que no hay sobrecarga del sistema anfitrión, el terminal es el mismo anfitrión sólo para los indicadores y EAs. Si el cálculo del indicador consiste en RSI(3) + EMA(5) + EMA(7), entonces por supuesto no hay problema en los próximos 10 años.

En el sintético (en realidad es un indicador multisímbolo del terminal) a los desarrolladores se les ocurrió de alguna manera pegar algunos símbolos, ¿por qué debemos duplicar los elementos de este sistema (supongamos que ni siquiera es perfecto) al nivel de la artesanía del programador en el indicador? Si el sistema puede simplificarse, ¿por qué no hacerlo? El tiempo de 5 segundos no se inventó en vano cuando la Tierra aún se sostenía sobre tres elefantes.

Upd. Se puede introducir el timeframe 5 segundos sin historia y los ticks serán sólo una vez en 5 segundos, y para probar todo tipo de soluciones (compilación del indicador con algún prefijo para trabajar sólo en 5S, otros indicadores no se ejecutarán en él) - la ideología existente del terminal no cambiará, por lo que podemos cambiar y modificar las soluciones, y la mejor / óptima solución se formará durante la prueba.

(LMS a sus bibliotecas de desarrollo, sintéticos, ventanas desprendidas, etc. Desarrolladores).

[fxsaber]

Unicornis:

Aunque haya un millón de ticks por minuto, esto no hace que la solución sea inviable.

[Unicornis]

fxsaber:

Un millón de ticks por minuto no hace que la solución sea inviable.

La cuestión no es la viabilidad de la solución. ¿La razonabilidad de llamar al indicador en cada tic alcanzado antes de que se pierda un número desconocido de tics, además, se considera cierta obsolescencia de un tic? Si se salta algo (con el aumento de la carga) y no se conoce la relevancia del tick, entonces esta situación no resuelve el problema analítico; si no, para qué molestarse. En general, prohíba el flujo de ticks en los indicadores, deje los ticks al indicador desde la plataforma una vez cada 5 segundos - 12 ticks por minuto, es suficiente.

[fxsaber]

Unicornis:

La cuestión no es la viabilidad de la solución. La razonabilidad de llamar al indicador en cada tic alcanzado antes del cual se perdió un número desconocido de tics, además de alguna obsolescencia de un tic se considera ??? Si se salta algo (con el aumento de la carga) y no se conoce la relevancia del tic, esta situación no resuelve el problema analítico; si no, para qué molestarse. En general, el flujo de ticks en los indicadores debe ser prohibido, los ticks que vienen de la plataforma cada 5 segundos deben ser dejados - 12 ticks por minuto, es suficiente.

La estupidez.