Errores, fallos, preguntas - página 672
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
¿Y las barras de la ventana cuánto cuestan?
El problema es que no se libera memoria en el terminal cuando se cambia el TF. Inicie el Administrador de Tareas, ponga el indicador en el gráfico y vea cómo crece la memoria. A continuación, cambie a otro TF y verá que la memoria empieza a crecer de nuevo. Pero lógicamente, cuando se cambia a otro TF, los datos del TF anterior deberían descargarse de la memoria. Como los datos de la TF anterior no se borran, la memoria crece hasta que se reinicia y genera un error. Si retira su indicador del gráfico, verá que después de un cierto período de tiempo la memoria se borra. Pero no se borra mientras el indicador está en funcionamiento.
Mi opinión: La solución a este problema es ServiceDec.
Gracias, primero borraré el indicador antes de cambiar el TF. Además he reducido las barras máximas de la ventana de 2000000 a 1000000 aparentemente MetaDriver quiere decirme eso.
Hasta ahora parece que funciona.
Gracias, borraré el indicador antes de cambiar el TF primero. Además, he reducido el número máximo de barras en la ventana de 2000000 a 1000000, al parecer MetaDriver quiere decirme eso.
Hasta ahora parece que funciona.
¿Por qué necesitas 100.000? 100.000 son suficientes para mí. Eso es lo que intento decirte.
No limita las pruebas a ninguna profundidad en absoluto.
Sólo limita (1) la visualización en ventanas (2) el tamaño de los buffers de los indicadores.
He restringido durante mucho tiempo y deliberadamente la "historia visible". El resultado: no tengo problemas de memoria.
¿Por qué necesitas un millón? 100.000 es suficiente para mí, que es exactamente lo que estaba insinuando.
No limita en absoluto las pruebas a ninguna profundidad.
Sólo limita (1) la visualización en las ventanas (2) el tamaño de los buffers de los indicadores.
He restringido durante mucho tiempo y deliberadamente la "historia visible". El resultado es que no tengo problemas de memoria.
Sí, gracias, voy a utilizar 108 pares en InstaForex aún más, para no tener problemas de memoria.
Es todo un tema. Ya en los primeros días de MT5 gritaba que todos los indicadores deberían tener un nuevo parámetro estándar : el número de barras a calcular.
De lo contrario, obtenemos el único limitador - TERMINAL_MAXBARS. Esto no es aceptable para los Asesores Expertos que analizan muchos símbolos en tiempo real utilizando indicadores. En la mayoría de los casos (99%) necesito en Expert Advisors un número estrictamente especificado de las últimas barras Y TODO. Todo lo demás es demasiado para mí. Por supuesto, no sólo para mí...
Fue ignorado. Como resultado, transferí dichos cálculos al código de mi Asesor Experto.
Ah, sí, y la aparición de muchos parches escritos por uno mismo. Incluso se escribieron y publicaron algunos artículos inteligentes, como el siguiente:
Disminuye el consumo de memoria de los indicadores auxiliares
Implementación de indicadores como clases mediante ejemplos de Zigzag y ATR
...
Si se separan los indicadores regulares mostrados y los indicadores cortos calculados, será fácil obtener divergencia en los indicadores largos acumulados.
Además, esto llevará a muletas peligrosas en nuestro lado.
Una buena manera es establecer 100000 barras por gráfico o cambiar a x64.
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
En general, nada cambia. Las solicitudes de la posibilidad de limitar el tamaño de las memorias intermedias de los indicadores en MQL5 son rechazadas, y si su programa comienza a consumir una enorme cantidad de memoria debido a la gran cantidad de memorias intermedias de los indicadores utilizados - entonces se llama "error de programación".
"En los Asesores Expertos, la mayoría de las veces (99%) necesito un número estrictamente específico de últimas barras Y TODO. Todas las cosas innecesarias son demasiado para mí. No sólo yo, por supuesto..." (с)
2) Los indicadores no pueden ser contados en un historial corto, porque son un recurso compartido entre todos los procesos (terminal, ventanas, expertos). Y hay muchas reglas de actualización, sincronización y recálculo del entorno del mercado en los indicadores.
3. Si se separan los indicadores regulares mostrados de los calculados a corto, será fácil obtener divergencia en los indicadores acumulados a largo.
Además, esto llevará a muletas peligrosas en nuestro lado.
1. una buena manera es establecer 100000 barras por gráfico o cambiar a x64.
1. Eso es lo que hice. Aun así, es un compromiso incómodo. Idealmente, si me quito de la cabeza los problemas de desarrollo por completo (puramente como usuario) me gustaría tener una opción a la hora de establecer la duración del cálculo. Para el gráfico - la longitud completa (aunque no siempre, hay serias y grandes excepciones), para los expertos - exactamente el tiempo necesario. 3.
2. Como desarrollador, entiendo las dificultades y las limitaciones simultáneas de este enfoque, y sin embargo el consumo de memoria es también mi problema, y tercamente no quiere caer en el fondo. Tengo una sugerencia-solución concreta - considerar el periodo de cálculo (llamémoslo así) como un parámetro igual-no peor que otros. Entonces, dos indicadores con todos los parámetros similares, pero con un período de cálculo diferente, son simplemente dos indicadores diferentes. Sí, teóricamente hay casos de uso estúpidos que pueden llevar a gastos adicionales (si el usuario multiplica los periodos de cálculo), pero en la práctica es poco probable. Si alguien quiere seguir con esto, es culpable. Igual que ahora TODOS los usuarios son culpables de "haber abierto demasiados indicadores y no haberse preocupado de reducir TERMINAL_MAXBARS".
Sé que en el cálculo de la EMA se utilizan todas las barras desde el principio del tiempo, pero también sé que en el estocástico, el RSI y en un número enorme(predominante) de otros indicadores el cálculo se realiza sobre una longitud orgánica . Y este conocimiento me permite la flexibilidad de elegir el período de cálculo (MaxBar). Sólo dame una opción.
Tanto como que ahora la culpa es de TODOS los usuarios por "abrir demasiados indicadores y no tener cuidado de reducir TERMINAL_MAXBARS".
Sí, especialmente en condiciones de campeonato cuando no puedes influir en el tamaño de TERMINAL_MAXBARS en absoluto.
1. Lo he hecho. Aun así, es un compromiso incómodo. Idealmente, si nos quitamos de la cabeza los problemas de desarrollo por completo (puramente como usuario) me gustaría tener una opción a la hora de establecer la duración del cálculo. Para el gráfico - la longitud completa (aunque no siempre, hay serias y grandes excepciones), para los expertos - exactamente el tiempo necesario. 3.
2. Como desarrollador, entiendo las dificultades y las limitaciones simultáneas de este enfoque, y sin embargo el consumo de memoria es también mi problema, y tercamente no quiere caer en el fondo. Tengo una sugerencia-solución concreta - considerar el periodo de cálculo (llamémoslo así) como un parámetro igual-no peor que otros. Entonces, dos indicadores con todos los parámetros similares, pero con un período de cálculo diferente, son simplemente dos indicadores diferentes. Sí, teóricamente, hay variantes tontas que pueden llevar a gastos adicionales (si el usuario multiplica los periodos de cálculo), pero en la práctica es poco probable. Si alguien quiere sobrepasar este tope - es su propia culpa. Al igual que ahora TODOS los usuarios son culpables de "haber abierto demasiados indicadores y no haberse preocupado de disminuir TERMINAL_MAXBARS".
Sé que en el cálculo de la EMA se utilizan todas las barras desde el principio del tiempo, pero también sé que en el estocástico, el RSI y un enorme número(predominante) de otros indicadores se calculan sobre una longitud orgánica . Y este conocimiento me permite la flexibilidad de elegir el período de cálculo (MaxBar). Sólo dame una opción.
El mensaje es claro.
Nosotros mismos queremos reducir el consumo de recursos. Tal vez la solución puede ser alguna función IndicatorMaxDepth(uint len) que actuará sólo en los indicadores creados en este EA.
Pero el problema es que durante las pruebas, los búferes de los indicadores en modo de acumulación crecerán junto con la historia y no habrá ningún ahorro. Recortar el historial del indicador en tiempo real, manteniendo la profundidad especificada, está plagado de bonitos fallos y deja boquiabiertos a los programadores, que cuentan/están acostumbrados al sincronismo de las barras del gráfico y del buffer del indicador.
Una mejor opción es pasar a x64.
Revisaremos el caché de los indicadores, que ahora utiliza el principio de máxima eficiencia frente al principio de ahorro de memoria. Intentaremos descargar los indicadores que fueron rechazados inmediatamente, en lugar de mantenerlos en la memoria durante algún tiempo, como hacemos ahora. Esto permitirá llamar a cientos de indicadores seguidos con una descarga directa a través de IndicatorRelease.
Por supuesto, si alguien va a llamar a cientos de indicadores en el modo de exploración del mercado sin descargarlos, entonces debe ir directamente a la versión de 64 bits + instalación de memoria adicional.
Ahora es extraño hacer pruebas masivas sentado en x32. Cualquier ordenador x64 decente con 16 GB de memoria (sin ser fanático de las tarjetas gráficas y los monitores) puede comprarse por 15.000 rublos.