
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
No, Vladimir. Está un poco mal.
En este caso, debe aplicar ArraySetAsSeries(array, false); a un array de trescientos elementos entre los que se considera iMAOnArray(). Pero es mejor que usemos CopyOpen() en lugar del bucle de llenado del array.
Según tengo entendido, en esta variante será mejor
No, Vladimir. Está un poco mal.
En este caso, debe aplicar ArraySetAsSeries(array, false); a un array de trescientos elementos entre los que se considera iMAOnArray(). Pero es mejor que usemos CopyOpen() en lugar del bucle de llenado del array.
Según tengo entendido, en esta variante será mejor
Esta es la cuestión. Si no necesito calcular todo el array, sino sólo los últimos N elementos.
No entiendo muy bien la lógica del cálculo de estas funciones al limitar. Tengo un array de series de tiempo (uno de los buffers de indicadores), si dejo el número de elementos igual a 0, no hay preguntas, todo se cuenta y se calcula, pero si disminuyo el número de elementos que intervienen en el cálculo por los mismos desplazamientos, sólo obtengo los primarios. Simplemente hay un array de 5000 elementos (barras en el gráfico), para ahorrar tiempo necesito calcular sólo los últimos 300, pero cuando especifiqué el valor 300 en el segundo parámetro obtuve los elementos primarios 5000-4700, pero en el offset 300-0, y los valores posteriores en una llamada no cambian. ¿Qué sentido tiene utilizar este parámetro?
El infierno lo sabe. Olvídate de ello. Si necesita acelerar los cálculos, reduzca el número de elementos que se calculan en su bucle.
Una de dos: o es imposible o se necesita alguna combinación secreta de direcciones de cálculo de series temporales, no de series temporales.
La mierda sabe. Olvídalo. Si quiere acelerar los cálculos, reduzca el número de elementos a calcular en su ciclo.
Una de dos: o es imposible o necesitas alguna combinación secreta de dirección de cálculo de series temporales, no de series temporales.
Sí, como ya escribí un poco antes, sólo hay una posibilidad - utilizar sus propios análogos de las funciones anteriores, que se pueden utilizar para calcular al menos un elemento.
Lo paradójico de la situación es que si hacemos una plantilla similar, superponiendo las barras de media o de bollinger sobre cualquier indicador (línea de precio), no habrá tal ralentización del cálculo inicial de todas las barras del historial, como cuando se utilizan estas funciones en el código, al reiniciar el terminal o cambiar el TF, por lo que no está claro, lo que tarda tanto en calcularse en estas funciones.
La mierda sabe. Olvídalo. Si quiere acelerar los cálculos, reduzca el número de elementos a calcular en su ciclo.
Una de dos: o es imposible o se necesita alguna combinación secreta de direcciones de cálculo de series temporales, no de series temporales.
También he utilizado una construcción de este tipo.
Por cierto, "MovingAverages.mqh" es dos veces más rápido que"iMAOnArray", incluso la versión antigua.
https://www.mql5.com/ru/forum/79988
Sí, como escribí un poco antes, sólo hay una opción - utilizar nuestros propios análogos de las funciones mencionadas donde es posible calcular al menos un elemento.
Lo paradójico de la situación es que si hacemos una plantilla similar adjuntando la MA y las bandas de Bollinger a cualquier indicador (línea de precio), no veremos tal ralentización del cálculo inicial de todas las barras del historial, como cuando se usan estas funciones en el código, al reiniciar el terminal o cambiar el TF, por lo que no está claro qué es lo que tarda tanto en calcular en estas funciones.
¿Se ralentiza incluso cuando se utiliza iMAOnArray? No debería existir tal cosa. Como tú, había lags de StdOnArray (o BandsOnArray, no recuerdo) los desarrolladores no admitieron la existencia del bug durante mucho tiempo. Luego, de repente, se arregló y funcionó rápidamente. Quién sabe, tal vez el bicho volvió. Si iMAOnArray() también provoca ralentizaciones notables, es un error. Parece que se habló de ello hace un par de meses... Pero sigue ahí, aparentemente.
¿La ralentización incluso por el uso de iMAOnArray? No debería ser así. Como en su día, hubo una ralentización de StdOnArray, los desarrolladores no reconocieron el fallo durante mucho tiempo. Luego, de repente, lo arreglaron y funcionó rápidamente. Quién sabe, tal vez el bicho volvió. Si iMAOnArray() también provoca ralentizaciones notables, es un error. Parece que se habló de ello hace un par de meses... Pero sigue ahí, aparentemente.
Es difícil juzgar si es demasiado lento o no, porque todo depende de la longitud del gráfico (número de barras), el problema es que para la optimización sólo hay que calcular un poco, y no se puede limitar la longitud del cálculo por el cálculo real.
Haga el cálculo conMovingAverages.mqh y lo calculará muy rápidamente.
Así que muéstrame la variante "de trabajo" del código, el código original está aquí, que está tratando de reducir a 12 elementos mostrados en lugar de la solicitada por mí trescientos, y debe terminar con 3 búferes indicadores con los datos especificados, por lo que al menos 300 elementos se mostraron en el sótano, Y luego, cuando venga una nueva barra, respectivamente, se dibujará 301 y luego el valor, pero no olvides que en este caso, si usas 0 como límite para el cálculo, sólo se recalculará la nueva barra, y el tipo de media (suavizado) para el segundo buffer no es necesariamente SMA, y puede ser cualquiera de los 4 disponibles.
Aquí tienes.