Un poco sorprendido :) Pensé en compartir y hacer una pregunta NO retórica. - página 5

 
hrenfx:

Pregunta a los desarrolladores:

¿El Asesor Experto con indicadores y el mismo Asesor Experto, pero con indicadores transferidos en su código ("todo en uno"), serán diferentes en términos de velocidad de ejecución en el probador? ¿En qué dirección?

Lo más probable es que no haya una respuesta definitiva a esta pregunta. Pero aun así le pido que aclare más o menos esta cuestión.

Recuerdo un comentario popular en el 4º foro de que en ausencia de la llamada a IndicatorCounted en los EAs, los indicadores que dependen de sus valores anteriores funcionarán con un gran efecto de frenado. Porque la expo tendrá que calcular todo el buffer en cada tick.

Así que si hablamos de primitivas del tipo Buf[i]=(High[i]+Low[i])/2, por supuesto que podemos implementarlas en el Asesor Experto y seguramente funcionará más rápido.

¿Por qué pones cara de incomprensión? ¿Te soluciona algo saber qué será más rápido?

Diviértete

 
¡Chicos, dejad de ser estúpidos! En la pregunta sobre la velocidad, preste atención a la palabra "probador". Sólo tiene sentido hablar de velocidad en el caso de los probadores y optimizadores. No se necesita IndicatorCounted() para el probador y el optimizador.
 

Los desarrolladores, si lo desean, confirmarán, para no mentir, que siempre pueden transferir indicadores al código del Asesor Experto con resultados absolutamente idénticos en el Probador. Pero al mismo tiempo no perderemos velocidad y obtendremos una gran oportunidad para una mayor optimización algorítmica. Una vez realizada dicha optimización, el "todo en uno" será en el TESTER siempre más rápido que su "hermano gemelo" indicador por definición.

La variante "todo en uno" es necesaria sólo para aquellos que aprecian la velocidad de ejecución en Tester y Optimizer. Además, la variante "todo en uno" se puede transferir fácilmente a su optimizador "en bruto" de escritura propia para realizar la optimización mucho más rápidamente.

 
Es comprensible, pues, que usted, hrenfx, escriba expertos únicamente para el probador.
 
hrenfx:
No se necesita IndicatorCounted() para el probador y el optimizador.

Aquí vamos... Con este enfoque, se consigue un freno salvaje en los cálculos.

Hay que aprender la teoría y mirar los indicadores estándar. Casi todos son económicos con IndicatorCounted() y recalculan sólo las últimas barras.

Sólo la corrección de uno de los errores de reinicialización de buffers en la última build de MT4 ha puesto de manifiesto los problemas de los indicadores que no tienen en cuenta IndicatorCounted().

 
Renat:

Aquí vamos... Con este enfoque, se consigue un freno salvaje en los cálculos.

Hay que aprender la teoría y mirar los indicadores estándar. Casi todos son económicos con IndicatorCounted() y recalculan sólo las últimas barras.

Sólo la corrección de uno de los errores de reinicialización del buffer en la última build de MT4 ha puesto de manifiesto los problemas de los indicadores que no consideran IndicatorCounted().

¿Cuál es la costumbre de sacar las cosas de contexto? Me refería a la ausencia de IndicatorCounted() en los EAs. Supuestamente, debido a esta ausencia, los EAs todo-en-uno tienen que recalcular lo mismo cien veces. Pero el IndicatorCounted() no es necesario en forma explícita en los Asesores Expertos, puede ser simplemente implementado a través de variables estáticas.

Inicialmente, estamos hablando de indicadores y Asesores Expertos escritos de forma competente "todo en uno" para TESTER. No estamos discutiendo el análisis de la mala mano. Estamos comparando la velocidad de dos enfoques en la escritura de EAs para Tester. Exactamente donde la cuestión de la velocidad es importante.

 
Renat:

Aquí vamos... Con este enfoque, se consigue un freno salvaje en los cálculos.

Hay que aprender la teoría y mirar los indicadores estándar. Casi todos son económicos con IndicatorCounted() y recalculan sólo las últimas barras.

Al arreglar uno de los errores de reinicialización de los buffers en la última build de MT4 se revelaron los problemas de los indicadores, que no consideran IndicatorCounted().

En el probador, las barras se reciben secuencialmente y no hay interrupciones en la comunicación. El tiempo del último compás está memorizado, por lo que sólo se recalcula un compás. Pero esto sólo será un juguete para el probador.

 
hrenfx:

....

Originalmente se trata de indicadores escritos de forma competente y de EAs todo en uno escritos de forma competente. No hay ningún informe sobre las manos torcidas. Lo que se está comparando es exactamente la velocidad de dos EAs escritos por expertos.

No te quedes callado sobre el contexto. Se habla de EAs "todo en uno" únicamente para trabajar en el probador.

 
Integer:

No te quedes callado ante el contexto. Se trata de un asesor todo en uno exclusivamente para el probador.

Especialmente para ti, vuelvo a escribir, como en todos los posts anteriores en mayúsculas, la velocidad es importante para Tester y optimizador. Por eso la velocidad sólo se tiene en cuenta para el Probador y el optimizador.

Velocidad y sólo velocidad.

Suponga que tiene dos resultados idénticos en TESTER, uno en indicadores y otro "todo en uno". El segundo funciona mucho más rápido. Es obvio que para optimizarlo, ejecutará la segunda variante (porque es más rápida) y encontrará los parámetros necesarios y los insertará en el Asesor Experto con el indicador, que ejecutará en la cuenta real, porque allí los mecanismos son más fiables para el comercio real.

Una vez más, estamos discutiendo la VELOCIDAD en el Probador.

 
hrenfx:

Especialmente para ti, vuelvo a escribir, como en todos los posts anteriores se escribió en mayúsculas, la velocidad es importante para el Probador y optimizador. Por eso, la velocidad sólo es un problema para el probador y el optimizador.

No tengo que escribir nada personalmente, sé leer, atención constante, buena memoria. Además, este mensaje, al que usted me respondió personalmente en mayúsculas, demostró mi conocimiento del konokst.