Discusión sobre el artículo "Zigzag universal" - página 2
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
Ninguna obra para especialistas puede convertirse en un bestseller por definición: hay pocos especialistas.
Por si acaso, no me incluyo entre ellos. El artículo es para los que acaban de empezar a dominar o están a punto de hacerlo. Es bueno.
Para que se entienda bien, daré enlaces a dos artículos.
¿Qué tienen que ver los enlaces que has citado con el tema del artículo?
Son relevantes para la discusión que se inició en los comentarios iniciales del artículo.
La discusión con los "viveros" en realidad toca un punto fundamental.
De hecho, el autor afirma que todos los Asesores Expertos que trabajan con series temporales (que es el 99% de los Asesores Expertos) deben recibir datos sobre ellas a través de indicadores (vía iCustom-mechanism) y sólo de esta manera. Por ejemplo, si quieres trabajar con precios de apertura, llama al indicador, cuyo buffer contiene esta serie temporal. El razonamiento no es nuevo - el mecanismo prev_calculated, que ha sido perfeccionado por los desarrolladores de más de 15 años de experiencia en la escritura de plataformas de negociación.
Un robot está operando. El broker, por error o intencionadamente, cambia algo en el historial de forma retroactiva. Prev_calculated se pone inmediatamente a cero y todos los indicadores se vuelven a calcular, incluidos los utilizados por el Asesor Experto. Es bastante difícil predecir cómo se comportará el Asesor Experto después de eso.
Si el Asesor Experto utilizara sólo un indicador como objeto OOP, la situación no sería peor. Por lo tanto, es difícil entender el razonamiento detrás del poder del mecanismo prev_calculated cuando se aplica a los Asesores Expertos.
En realidad, la discusión sobre la "guardería" toca un punto fundamental.
1. De hecho, el autor afirma que todos los Asesores Expertos que trabajan con series temporales (que es el 99% de los Asesores Expertos) deben recibir datos sobre ellas a través de indicadores (vía iCustom-mechanism) y sólo de esta manera. Por ejemplo, si quieres trabajar con precios de apertura, llama al indicador, cuyo buffer contiene esta serie temporal. El razonamiento no es nuevo - el mecanismo prev_calculated, que ha sido perfeccionado por los desarrolladores de más de 15 años de experiencia en la escritura de plataformas de negociación.
2. el robot negocia. El broker, por error o intencionadamente, cambia algo en el historial de forma retroactiva. Prev_calculated se pone inmediatamente a cero y se recalculan todos los indicadores, incluidos los utilizados por el Asesor Experto. Es bastante difícil predecir cómo se comportará el Asesor Experto después de esto.
3. Si el Asesor Experto utilizara sólo el indicador como un objeto OOP, la situación no sería peor. Por lo tanto, es difícil entender el razonamiento detrás del poder del mecanismo prev_calculated cuando se aplica a los Asesores Expertos.
1. Nada de eso. Sólo afirmo que calcular indicadores en un Asesor Experto es una enorme tontería.
2. Se comportará con normalidad, nada raro. Nadie sabe qué lecturas tendrá el indicador en la siguiente barra, pero hasta ahora no ha habido ninguna inundación global por su parte.
3. ¿Qué tiene que ver OOP con esto?1. Nada de eso. Sólo afirmo que el cálculo de indicadores en el Asesor de Expertos es una gran locura.
¿Es prev_calculated la razón? Dime la razón.
2. Se comportará normalmente, nada inusual. Nadie sabe lo que mostrará el indicador en la siguiente barra, pero hasta ahora no ha habido ninguna inundación global.
3. ¿Qué tiene que ver la POO en todo esto?Es conveniente simplemente referirse al indicador en el Asesor Experto a través de Indicador[NumBuffer][Pos]. Por lo tanto, estamos hablando de OOP. En lugar de iCustom hacer nuevo Indicador. En este caso, todo estará dentro de la EA. En consecuencia, el código será aún más óptimo.
Es decir, es lógico escribir un indicador OOP tanto para la visualización como para el EA.
1. ¿Es prev_calculado la causa? Indique la razón.
2. Es conveniente simplemente hacer referencia al indicador en el Asesor de Expertos a través de Indicador[NumBuffer][Pos]. Por lo tanto, estamos hablando de OOP. En lugar de iCustom haga new Indicator. En este caso, todo estará dentro del EA. En consecuencia, el código será aún más óptimo.
Es decir, es lógico escribir un indicador OOP tanto para la visualización como para el Asesor Experto.
1. Sí, en prev_calculated. La única, innegable e insalvable. Si alguien opina diferente, es un iluso.
2. iCustom también se puede utilizar a través de una junta en forma de OOP. Es una cuestión personal y no cambia nada en lo fundamental. La cuestión es que sugieres lo que tú mismo desconoces, sugieres calcular indicadores en el Asesor Experto, pero mira el punto 1 aquí y en mi post anterior.
1. Sí, lo es. La única, innegable e irresistible. Si alguien tiene una opinión diferente, es un iluso.
2. iCustom también se puede utilizar a través de un relleno en forma de OOP. Es una cuestión personal y no cambia nada en lo fundamental. La cuestión es que propones lo que tú mismo desconoces, propones calcular indicadores en el Asesor Experto, pero mira el punto 1 aquí y en mi post anterior.
Afirmo que el código de los indicadores dentro del Asesor Experto no es inferior y no requiere visualización (buffers).
He resaltado tu respuesta en negrita. Un argumento, sin embargo.
1. Afirmo que el código de los indicadores dentro del Asesor Experto no es inferior y no requiere visualización (buffers).
He resaltado su respuesta en negrita. Sin embargo, un argumento.
1. Afirmación sin fundamento y errónea.
2. Argumento.