Errores, fallos, preguntas - página 2179
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, no tiene nada que ver con la carga.
Si no se toma una barra de inicio cero, sino digamos 50 barras, entonces todo está bien. Instantáneo.
Y si lo llevo hasta los 30 bares inclusive, se congela. Después, no lo hace.
¡DEFINITIVAMENTE ES UN ERROR!
Prueba con este:
Prueba con este:
¿Qué tiene que ver iBarShift con todo esto?
Se trata de un error en la función estándar de Bares
¿Qué tiene que ver iBarShift con todo esto?
Se trata de un error en la función estándar de Bares
Esta función también utiliza Bars(). Has empezado con el análogo de iBarShift()
Esta función también utiliza Bars(). En su caso, todo comenzó con el análogo de iBarShift()
Sí, por supuesto, el uso de la contraparte de iBarShift reveló este problema.
Si se utiliza la función iBarShift dada por usted, no se detectará este error, porque sólo se utiliza un TF allí,
Y este error se produce cuando se utilizan diferentes TF en las funciones CopyTime y Bars.
Pero Bares debería funcionar normalmente para cualquier momento. Pero mi ejemplo muestra que hay un caso especial, donde iBar se cuelga durante decenas de segundos. Y no tiene nada que ver con cargar la historia.
Sí, por supuesto, el uso de la contraparte de iBarShift reveló este problema.
Si se utiliza la función iBarShift dada por usted, no se detectará este error, porque sólo se utiliza un TF allí,
Y este error ocurre cuando se utilizan diferentes TF en las funciones CopyTime y Bars.
Pero Bares debería funcionar normalmente para cualquier momento. Pero mi ejemplo muestra que hay un caso especial, donde iBar se cuelga durante decenas de segundos. Y no tiene nada que ver con cargar la historia.
Lo más probable es que esto se deba a la carga de la historia
Sí, por supuesto, el uso de la contraparte de iBarShift reveló este problema.
Si se utiliza la función iBarShift dada por usted, no se detectará este error, porque sólo se utiliza un TF allí,
Y este error ocurre cuando se utilizan diferentes TF en las funciones CopyTime y Bars.
Pero Bares debería funcionar normalmente para cualquier momento. Pero mi ejemplo muestra que hay un caso especial, donde iBar se cuelga durante decenas de segundos. Y no tiene nada que ver con cargar la historia.
Creo que hay un intento de sincronización cíclica en una situación en la que no hay barras en el rango solicitado - Bares se esfuerza por "trabajar normalmente" y luego se rinde por un tiempo de espera o número de intentos de sincronización.
Debería comprobar los valores usted mismo para evitar llamar a Bars en tal caso.
Lo más probable es que esto se deba a la carga del historial
No estoy de acuerdo. No se habría descargado de nuevo durante 22 segundos. Además, tengo todo el historial de todos los TFs cargados por un indicador especial.
Si fuera una carga, entonces cómo se explica que los primeros 31 compases necesiten carga y los siguientes no.
Si fuera una subcarga, entonces cómo se explica que los primeros 31 compases necesiten una subcarga y los siguientes no.
De la documentación: Cuando se solicita el número de barras en un rango de fechas determinado, sólo se tienen en cuenta las barras cuya hora de apertura se encuentra dentro de este rango.
En consecuencia, el prototipo Bars() devuelve cero, lo que se interpreta como que no hay historia y ::Bars() en el caso del script, como se señaló correctamente en un post anterior, termina por tiempo de espera o por el número de intentos fallidos.
Creo que hay un intento de sincronización cíclica cuando no hay barras en el rango solicitado - Bares se esfuerza por "trabajar normalmente" y luego se rinde por el tiempo de espera o el número de intentos de sincronización
La razón de estos casos es que no debe llamar a Bars para comprobar los valores por sí mismo.
Es muy posible.
Pero hay muchas opciones.
Las barras son una función muy importante, y es difícil prescindir de ellas. Para ser exactos, puedes prescindir de él, pero te costará muchos recursos.
Debes asegurarte de que funciona perfectamente.
De la documentación: Al solicitar el número de bares en un rango de fechas determinado, sólo se tienen en cuenta los bares cuyos horarios de apertura se encuentran dentro de este rango .
En consecuencia, el prototipo Bars() devuelve cero, lo que se interpreta como una falta de historia y el script, como se señaló correctamente en un mensaje anterior, termina por tiempo de espera o número de intentos fallidos.
Está claro que es cero.
¿Y qué? ¿Está bien que se tarden 22 segundos en decidir que hay cero barras en un rango de tiempo determinado?
Hay un error algorítmico evidente en la implementación interna de Bares.
Deberíamos enviar una solicitud al Service Desk sobre este tema - el fin de semana está por delante y el tema podría perderse el lunes.