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
Ya no habrá más ticks con la última hora conocida.
El OnTimer en milisegundos garantiza que hayan transcurrido todos los ticks ANTERIORES a este evento del temporizador. Es decir, los ticks están actualizados para todos los símbolos.
Si se refiere a que el indicador espía, por alguna razón técnica, pueda retener un «tik antiguo» y enviarlo después de uno más reciente de otro instrumento, es probable que eso pueda ocurrir. Por lo demás, no veo ningún problema directamente en el código.
No creo que el temporizador garantice en mayor medida que todos los ticks hayan transcurrido ANTES del nuevo «evento» (recorrido de una unidad de tiempo). El temporizador funciona en hora local, mientras que las marcas de tiempo de los ticks contienen la hora del servidor. Por eso, es mejor no basarse en el temporizador para sincronizar los instrumentos.
De acuerdo, para los ticks esto es aceptable, dada la complejidad de la sincronización, aunque podríamos establecer un intervalo de milisegundos y ajustar los ticks en el tiempo.
Pero ocurre lo mismo con los precios de apertura, aunque la hora de apertura sea la misma para todos los símbolos.
Y debido a este comportamiento, es imposible probar correctamente una serie de sistemas.
Demostración del problema.
En la captura de pantalla se muestran todos los datos necesarios para reproducir el problema en MetaQuotes-Demo. Se aprecia claramente que, con OnTick, los ticks no están sincronizados, mientras que con OnTimer (que ralentiza muchísimo el sistema) sí lo están.
A través de OnTick, los ticks no están sincronizados, mientras que a través de OnTimer (que ralentiza muchísimo el sistema) sí lo están.
Parece que la única forma de acelerar los cálculos en modo sincronizado es el modo matemático, similar a EAToMath.
O bien, guardar previamente en un archivo estos datos de una sola pasada.
Y en el propio asesor técnico, utilizar los datos de ese archivo para la sincronización en OnTick. Funcionará rápido y correctamente.
Demostración del problema.
En la captura de pantalla se muestran todos los datos necesarios para reproducir el problema en MetaQuotes-Demo. Se aprecia claramente que, con OnTick, los ticks no están sincronizados, mientras que con OnTimer (que ralentiza muchísimo el sistema) sí lo están.
Bueno, pues has utilizado tu código con la condición de entrada en la operación mediante ==. Ya he indicado anteriormente que la condición debe ser estrictamente >, sin el signo igual. Para realizar operaciones sincronizadas con los últimos precios conocidos hasta el 01/10/2025 a las 01:00:00.081 en todos los instrumentos, debes empezar a monitorizar los ticks antes de esa hora, es decir, tomar como constante de demostración, por ejemplo, >1759280400080. Para cada algoritmo hay que modificar la lógica; no bastará con sustituir un tipo de procesador por otro.
PD: Por «sincronización» me refiero a operar con los últimos precios conocidos. Para la sincronización por igualdad de milisegundos se necesitan, por supuesto, comprobaciones adicionales, pero la probabilidad de que se den esas situaciones (coincidencia de milisegundos de los ticks de diferentes instrumentos) es baja, lo que implica la pérdida de posibles señales. No estoy seguro de que esa sincronización tenga interés práctico.
Para realizar operaciones sincronizadas a los últimos precios conocidos hasta el 1 de octubre de 2025 a las 01:00:00.081 en todos los instrumentos, debe comenzar a supervisar los ticks antes de esa hora, es decir, tomar como constante de demostración, por ejemplo, >1759280400080.
La forma más sencilla de sincronizar es crear un conjunto a partir de los tiempos de los tics de los símbolos utilizados.
Es complicado realizar la sincronización sobre la marcha, en una sola pasada.
La dificultad radica en la incertidumbre del retraso. No se sabe qué símbolo será el de referencia.
Estoy dispuesto a echar un vistazo a tu versión en el código.
Para poder crear un caso de prueba completo, necesitaría entender el problema práctico: ¿operamos únicamente con ticks cuya hora coincida con una precisión de milisegundos?
Para un ejemplo artificial con una única operación en un momento conocido de antemano, con ticks sincrónicos en todos los instrumentos, se podría idear un algoritmo óptimo artificial, pero ¿para qué?
Pero los precios de apertura son los mismos, aunque la hora de apertura sea la misma para todos los valores.
Habría que precisar el problema. En cuanto a los precios de apertura, si el algoritmo requiere la presencia de barras de todos los símbolos, esperamos a que iTime(,,0) coincida en todos los símbolos. Para las barras, en este enfoque no suele haber ningún problema lógico, ya que las barras (incluso las de M1) rara vez faltan; sin embargo, para los segundos y las unidades de tiempo más pequeñas, los fallos de sincronización pueden ser frecuentes. ¿Qué hay que hacer en esos momentos?
Creo que, en la práctica, para la sincronización se debería tener en cuenta la presencia de cualquier precio que no sea anterior a un tiempo de espera determinado, y no la igualdad estricta de las marcas de tiempo de los ticks.
Habría que precisar el problema. En cuanto a los precios de apertura, si el algoritmo requiere la presencia de barras de todos los símbolos, esperamos a que iTime(,,0) coincida en todos los símbolos. En este enfoque, normalmente no hay ningún problema lógico con las barras, ya que rara vez faltan (ni siquiera en M1).
Me refiero al modo de prueba con precios de apertura.
Para segundos e intervalos de tiempo más pequeños, los fallos de sincronización pueden ser frecuentes. ¿Qué hay que hacer en esos momentos?
Utilizar el último valor conocido.