Un poco sorprendido :) Pensé en compartir y hacer una pregunta NO retórica. - página 7
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
La cuestión no está en el probador, ¡otra vez! No en el probador, sino en condiciones reales donde se descarga el historial y se producen fallos de conexión.
Si en la vida real se produce un reinicio y un nuevo cálculo del indicador, no hay nada malo en ello.
Ha surgido otra cuestión. ¿No tiene la mayoría de la gente nada que hacer aquí? Están reescribiendo la funcionalidad estándar del terminal para mql5. Quizás, alguien escriba un terminal completo sobre mql5 muy pronto.
Si, en condiciones reales, se produce un reinicio y un nuevo cálculo del indicador, no hay nada malo en ello.
Ha surgido otra cuestión. ¿No tiene la mayoría de la gente nada que hacer aquí? Están reescribiendo la funcionalidad estándar del terminal para mql5. Quizás, alguien escriba un terminal completo sobre mql5 muy pronto.
Por supuesto, no es tan malo. Cuando tienes 100 ZUP en un terminal (sólo por ejemplo), está bien...
La misma pregunta surgió. A todo el mundo le gusta hablar sólo desde su punto de vista, ¿por qué?
Aquí se utiliza más de un indicador:
La influencia de la función estándar IndicatorCount es simplemente mortal para ello (lo he comprobado personalmente). Y cuando se implementan como clases, las discontinuidades en la comunicación son aún más moradas
P.D. Para un MA no es, por supuesto, un gran problema
Por supuesto que no es gran cosa. Cuando tienes 100 ZUPs en un terminal (por poner un ejemplo), no es gran cosa...
Se ha planteado la misma cuestión. A todo el mundo le gusta discutir sólo desde su propio campanario, ¿por qué?
Alguien siempre quiere más de lo que puede manejar. Pero, ¿por qué tantos?
El problema de reiniciar el indicador se puede resolver con cinco líneas de código. Recuerda la hora del primer compás, si ha cambiado, necesitas un recálculo completo. Almacena el número de la última barra, en caso de reinicio continúa el recálculo desde esta barra y ya está.
No tengo miedo de decir desde mi propio campanario, sin confirmar nada con argumentos que mi campanario es correcto y punto.
Alguien siempre quiere más de lo que puede manejar. Pero, ¿por qué tanto?
Puedes evitar el problema de reiniciar el indicador con cinco líneas de código. Recuerde la hora del primer compás, si ha cambiado, es necesario un recálculo completo. Almacena el número de la última barra, en caso de reinicio continúa el recálculo desde esta barra y listo.
No tengo miedo de decir desde mi campanario, sin confirmar nada con argumentos que mi campanario es correcto y ya está.
No seas tan santurrón. Aprende no sólo a escuchar, sino a oír a los demás.
La historia puede cambiar a mitad de camino y tu planteamiento se irá al garete. Pregúntale a Renat sobre esto.
El error en IndicatorCounted() en MT4, que fue arreglado con mi consejo sólo ahora, envió incluso los indicadores correctamente escritos a la chatarra (especialmente ZigZag en pequeños TFs).
Por no hablar de su enfoque de este caso....
Ni siquiera voy a discutir contigo porque estás completamente equivocado en esta situación.
No tengas tanta confianza en ti mismo. Aprende no sólo a escuchar, sino también a oír a los demás.
La historia puede cambiar a mitad de camino y su planteamiento se irá al garete. Pregúntale a Renat sobre esto.
El error en IndicatorCounted() en MT4, que fue corregido sólo ahora con mi consejo, envió incluso los indicadores correctamente escritos a la basura (especialmente ZigZag en pequeños TFs).
Ni siquiera voy a discutir contigo, porque estás completamente equivocado en esta situación.
Añade un par de comprobaciones más en el momento del reinicio, si el número de compases ha aumentado, pero el tiempo de compás no ha cambiado o se ha añadido más de un compás.
En cuanto al exceso de confianza, es al revés, el exceso de confianza eres tú, eres el tercero que se cree más guay que MQ.
Añade un par de comprobaciones más en el momento de la puesta a cero, si el número de compases ha aumentado pero el tiempo de compás no ha cambiado o si se ha añadido más de un compás.
Sobre lo de la autoconfianza, es al revés, aquí todos sois los que tenéis un exceso de confianza, eres el tercero que se cree más guay que MQ.
¿Qué tipo de cheques? Situación. Aparece una nueva marca en la barra anterior. No ha cambiado nada, ni el número total de compases, ni el tiempo de apertura del último compás.
lasúltimas 30 barras han sido reescritas (sus precios de apertura/cierre, máximo, mínimo, han cambiado, aunque de forma insignificante).
¿Qué vas a hacer con tu algoritmo? ¡Nada! Simplemente no funcionará en esta situación. Y el indicador será completamente incorrecto.
Lo que había en MT4 antes de los últimos builds - en el 70% de los casos no reaccionaba a esta situación.
Pero tras el análisis de este problema lo han solucionado. Stingo escribió al respecto: https://www.mql5.com/ru/forum/132422
No creo que sea más guay que los demás. Por el contrario, ayudo activamente a arreglar todos los errores en MT4 y MT5 - pregunte a cualquier representante de MetaQuotes.
Y el hecho de que algunos mecanismos no se apliquen de la manera deseada: no se puede complacer a todo el mundo....
Es una cuestión interesante saber qué es lo correcto, lo que había antes o lo que había después de la corrección de la historia. Si no se vuelve a las barras corregidas, el indicador seguirá funcionando como si el historial no estuviera corregido. Hrenfx tiene exactamente esta actitud, considera que la historia antigua es correcta, tú tienes lo contrario.
También existe la opinión de que sólo se debe utilizar prev_calculado regular, sin variaciones. Si el indicador es pesado, limite el número de barras contadas al inicio. El resto es un baile de pandereta, el resultado es dudoso.
Es una cuestión interesante saber qué es lo correcto, lo que había antes o lo que había después de la corrección de la historia. Si no se vuelve a las barras corregidas, el indicador seguirá funcionando como si el historial no estuviera corregido. Hrenfx tiene exactamente esta actitud, considera que la historia antigua es correcta, tú tienes lo contrario.
También existe la opinión de que sólo se debe utilizar el prev_calculado regular, sin variar. Si el indicador es pesado, limite el número de barras contadas al inicio. Lo demás es bailar con pandereta, el resultado es dudoso.
Cada uno decide por sí mismo lo que se considera correcto y lo que no. Para ZigZag la situación anterior es totalmente mortal. Para MA, habrá una desviación de 0,0001 en su valor...
La opinión puede ser a menudo impuesta (no digo que esté mal).
En general, sugiero terminar la discusión aquí. Los razonamientos teóricos no te llevarán a ninguna parte.
En el probador, la optimización personalizada de los cálculos del indicador funcionará perfectamente, pero en el terminal del cliente puede provocar desplazamientos desagradables del historial y cálculos incorrectos.
Por cierto, mt5 utiliza un control muy eficaz e instantáneo de la integridad de la base histórica en rltime, lo que aumenta la frecuencia de reposición de prev_counted a cero. Si no se tiene en cuenta este contador correctamente, y se ocupa de sus propias optimizaciones, se pueden coger muchos problemas en el trabajo real. Las actualizaciones del historial de minutos son entregadas instantáneamente a los terminales por el propio servidor.
En el probador, la optimización personalizada de los cálculos de los indicadores funcionará perfectamente, pero en el terminal del cliente, el historial se desplaza y pueden aparecer cálculos incorrectos.
Eso es lo que quiero decir también.
¿Quizá se te ocurra cómo restablecer prev_counted no a cero, sino al primer valor no modificado?