Error en MQL5 al trabajar con el acceso a series temporales iClose/iOpen, etc. - página 8
![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Es posible tratar de determinar.
Si son minutos, puede comparar el tiempo de la última barra con TimeCurrent(). Si no es M1, puede pedir iTime(_Symbol,PERIOD_M1,0) y comparar con TimeCurrent().
Puede comparar el precio de compra o de venta (según el símbolo) con el precio de cierre de la última barra. Puede preguntar directamente a SymbolInfoTick por el símbolo actual. Además de la Oferta y la Última, también está la hora de la garrapata
Gracias, al menos algo de información sobre dónde y cómo buscar los fallos si algo va mal
pero creo, que todos los mismos necesitan función incrustada para comprobar el estado, o mejor aún sería una bandera, como int _LastError, que almacenaría el número de ticks perdidos, sería conveniente cuando se llama OnCalculate() - en los cálculos complejos hacer inmediatamente volver, para liberar el flujo de símbolos
Gracias, al menos algo de información sobre dónde y cómo buscar los fallos si algo va mal
pero creo, que todos la misma necesidad de la función incrustada para comprobar el estado, o mejor aún, sería una bandera, como int _LastError, que almacenaría el número de garrapatas perdido, sería conveniente cuando se llama OnCalculate() - en los cálculos complejos hacer inmediatamente volver, para liberar el flujo de símbolos
pensó, reflexionó.... esta no es la solucion. cual sera el conocimiento de los ticks perdidos (Slava dice, que esta garantizado que el indicador recibe TODOS los ticks, y este hecho lleva a todos los cuelgues no solo de los programas MQL, sino incluso del terminal del cliente)? en cualquier caso, estos ticks tendran que ser recogidos y procesados, y eso significa, que si nos perdimos un tick, ¿por que esperar de repente que la proxima vez sea posible? - es un círculo vicioso.
Estaba pensando... La llegada de un nuevo tick debería interrumpir todas las operaciones, cálculos en el indicador en ese momento, y cualquier función MQL estándar debería devolver un error durante su ejecución, si un nuevo tick llega en ese momento ... Entonces el trabajo con el indicador se vuelve claro, conveniente y predecible. Para los otros tipos de programas (scripts, Asesores Expertos) es casi innecesario.
Y todo tipo de comprobaciones de ticks en el indicador para su relevancia - por decirlo suavemente, esta no es la solución.
Tenemos una idea para los indicadores, que no contienen la bandera #property tester_everytick_calculate, para incluir el modo de cálculo basado en la recepción de ticks, en lugar de en cada tick.
Esto resolverá radicalmente el problema de la lentitud de los indicadores, preservando la posibilidad de garantizar el procesamiento de cada tick para algunos indicadores.
Tenemos una idea para los indicadores, que no contienen la bandera #property tester_everytick_calculate, para incluir el modo de cálculo sobre la base de la recepción de un paquete de ticks, en lugar de en cada tick.
Esto resolverá drásticamente el problema de los indicadores retrasados, preservando la posibilidad del procesamiento garantizado de cada tick para algunos indicadores.
Entonces, ¿podrá tener un indicador muy rápido con un diseño así?
Si es así, ¡es una gran noticia!
Tenemos una idea para los indicadores, que no contienen la bandera #property tester_everytick_calculate, para incluir el modo de cálculo sobre la base de la recepción de un paquete de ticks, en lugar de en cada tick.
Esto resolverá radicalmente el problema de la lentitud de los indicadores, preservando la posibilidad de garantizar el procesamiento de cada tick para algunos indicadores.
Y si se hace una función estándar para obtener una matriz multidivisa sincronizada, será un verdadero día de fiesta.
Tenemos una idea para los indicadores, que no contienen la bandera #property tester_everytick_calculate, para incluir el modo de cálculo sobre la base de la recepción de un paquete de ticks, en lugar de en cada tick.
Esto solucionará radicalmente el problema de la lentitud de los indicadores, conservando la posibilidad del procesamiento garantizado de cada tick para algunos indicadores.
¡Buena idea!
Y preferiblemente debería funcionar sin ninguna#propiedad por defecto.
Si alguien lo necesita de otra manera, que ponga#propiedad.
Pero hay otra clase de problemas: en tiempo real, en cada tic. En este caso, o bien tiene tiempo para hacer los cálculos después de un tick antes de que llegue el siguiente, o no, y entonces la solución comercial será irrelevante (no hay una tercera vía). Por eso sólo hay una forma correcta de resolver el problema: interrumpir todos los cálculos actuales y devolver el error cuando llegue un nuevo tick. Si no, podemos olvidarnos del tiempo real. Ahora los ticks son cada vez más rápidos, y queda un largo camino por recorrer, por lo que es necesario planificar el futuro, por no mencionar el hecho de que es imposible procesar todos los ticks sin retrasos en el tiempo en el presente.
La solución para recibir ticks en paquetes es buena y probablemente no muy cara, si no necesitamos tiempo real (pero no está claro cómo funcionarán los EAs con indicadores que trabajan a precios de "ayer", pero da igual).
Pero hay otro tipo de tareas: en tiempo real, en cada momento. O se tiene tiempo para realizar estimaciones tras la recepción de un tick o no se tiene, y la solución comercial será irrelevante (no hay una tercera alternativa). Por eso sólo hay una forma correcta de resolver el problema: interrumpir todos los cálculos actuales y devolver el error cuando llegue un nuevo tick. De lo contrario, uno puede olvidarse del tiempo real. Ahora los ticks son cada vez más rápidos, y queda mucho camino por recorrer, por lo que es necesario planificar el futuro, por no mencionar el hecho de que es imposible procesar todos los ticks sin retrasos en el tiempo en el presente.
La mayoría de los indicadores EAs trabajan con barra cerrada[1], por eso la omisión de ticks no importa, es actual para los indicadores que trabajan con ticks, pero no hay muchos de ellos, para ellos es posible asignar"#propiedad tester_everytick_calculate".
Y de nuevo, si usted necesita super-ticks, no necesita un indicador para eso, todo esto puede ser escrito en el código del Asesor Experto. Por tanto, no es razonable ralentizar el trabajo del indicador por cada tick.
Esperamos"#property tester_everytick_calculate".
La mayoría de los indicadores EAs trabajan con barra cerrada[1], por eso la omisión de ticks no importa, es actual para los indicadores que trabajan con ticks, pero no hay muchos de ellos, para ellos es posible asignar"#propiedad tester_everytick_calculate".
Y de nuevo, si usted necesita super-ticks, no necesita un indicador para eso, todo esto puede ser escrito en el código del Asesor Experto. Por tanto, no es razonable ralentizar el trabajo del indicador por cada tick.
Esperando"#property tester_everytick_calculate"