El problema de la transferencia de MT4 a MT5. O, más precisamente, la incapacidad de ejecutar algunos algoritmos en MT5 sin'err. - página 7
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
La tontería está en organizar tu propia copia de los datos, que ya están disponibles en el terminal.
Hay muchas tonterías de este tipo. Cuando se lanzó MT4 en agosto de 2005, apareció el indicador ZigZag. Hay muchos errores ahí. En un caso podría colgar el terminal en el mercado rápido en ese momento. Y a menudo mostraba extremos en el aire, no relacionados con los mínimos/máximos de las barras.
En un post el desarrollador de este zigzag dijo que esto - (por favor, no tome ninguna emoción más) es una manifestación de la lógica difusa........
Pero hasta ahora, han pasado 14 años desde el lanzamiento de MT4, en el indicador del zigzag hay un parámetro - Desviación - que no produce ninguna acción. Es decir, no importa el valor de este parámetro, el dibujo del zigzag en el gráfico no cambiará.
Muchos programas se basan en este indicador. La mayoría de los desarrolladores incluyen este parámetro en sus programas. Es un parámetro inútil. Los desarrolladores muestran una fantástica indiferencia al respecto. Este parámetro, por cierto, se come los recursos del ordenador.
Hubo muchos momentos así en otras ocasiones.
Continuaré.
Esos extremos en zigzag que cuelgan en el aire son exactamente de la misma naturaleza que los que tenemos al acceder a las series temporales.
Es que el acceso a las series de tiempo no fue negado en MT4. Algunas funciones no funcionaban correctamente allí (tal vez lo sigan haciendo ahora). Tenía una explicación para mi propio uso interno. También hice uno forzado por mi cuenta. Y todo empezó a funcionar sin errores, sin carga de la CPU. Incluso la salida de varias docenas de zigzags en los gráficos no hizo que el terminal se colgara...
Si todo funcionara, no habría un millón de temas dedicados a este problema.
La lógica resultó ser más complicada de lo que los usuarios de terminales están dispuestos a manejar.
Y debe haber errores, pero los desarrolladores no tienen tiempo para buscarlos, y tampoco nadie quiere reproducirlos y probarlos entre los usuarios.
Andrei, sugiero que empecemos con lo que tenemos. Y ya que tenemos lo que se dice, ¿es mejor hablar de ello, o evitarlo?
Creo que hay bastantes problemas, pero en lugar de hablar de ellos de rama en rama (que también es útil - a veces se arreglan), pero hacer la solución.
Y sugerí una buena opción: almacenar en caché las series temporales necesarias en el momento de su plena disponibilidad. Y luego - obtener todos los datos necesarios de series temporales listas y siempre disponibles. Y sólo complementarlos con nuevos datos. Cuando estén disponibles: lentamente y no necesariamente en el momento en que los necesite.
Al menos así las cosas avanzarán. Y las conversaciones pueden dejarse para más tarde, cuando no haya nada que hacer.
Continuaré.
Esos extremos en zigzag que cuelgan en el aire son exactamente de la misma naturaleza que los que tenemos al acceder a las series temporales.
Es que el acceso a las series de tiempo no fue negado en MT4. Algunas funciones no funcionaban correctamente allí (tal vez lo sigan haciendo ahora). Tenía una explicación para mi propio uso interno. También hice uno forzado por mi cuenta. Y todo empezó a funcionar sin errores, sin carga de la CPU. Incluso la salida de varias docenas de zigzags a los gráficos no hizo que el terminal se colgara...
Si se deniega el acceso a la serie temporal, significa que está en la fase de sincronización. Tienes que esperar hasta el siguiente tic.
En su situación - mejor almacenar en caché las series de tiempo - siempre estarán disponibles sin esperar, y a la primera solicitud.
Caché cuando el indicador se inicia - cuando hay tiempo para "esperar la sincronización" y mientras se espera para solicitar datos para la siguiente serie temporal.
Andrei, estoy sugiriendo que debemos ir con lo que tenemos. Y ya que tenemos lo que se dice, ¿es mejor hablar de ello, o dar un rodeo?
Creo que hay bastantes problemas, pero en lugar de hablar de ellos de rama en rama (que también es útil - a veces se arreglan), pero hacer la solución.
Y sugerí una buena opción: almacenar en caché las series temporales necesarias en el momento de su plena disponibilidad. Y, además, recibir todos los datos necesarios de series temporales listas y siempre disponibles. Y sólo complementarlos con nuevos datos. Al mismo tiempo, cuando estén disponibles, sin prisas y no necesariamente en el momento en que se necesiten.
Al menos así las cosas avanzarán. Y las conversaciones pueden dejarse para más tarde, cuando no haya nada que hacer.
Entonces ya es más efectivo hacer un ejemplo reproducible para que los desarrolladores lo arreglen.
Andrei, estoy sugiriendo que debemos ir con lo que tenemos. Y ya que tenemos lo que se dice, ¿es mejor hablar de ello, o rodearlo?
Creo que hay bastantes problemas, pero en lugar de hablar de ellos de rama en rama (que también es útil - a veces se arreglan), haz la solución.
Y sugerí una buena opción: almacenar en caché las series temporales necesarias en el momento de su plena disponibilidad. Y luego recibir todos los datos necesarios de series temporales listas y siempre disponibles. Y sólo complementarlos con nuevos datos. Al mismo tiempo, cuando estén disponibles, sin prisas y no necesariamente en el momento en que se necesiten.
Al menos así las cosas avanzarán. Y las conversaciones pueden dejarse para más tarde, cuando no haya nada que hacer.
¿Y por qué no pueden hacerlo los desarrolladores del terminal? De todos modos, no hay acceso a las series temporales en el momento de la actualización. Que todo el mundo tenga acceso a este, digamos, historial en caché. ¿Qué diferencia habría? Es decir, para que nunca se interrumpa el acceso. Bueno, tal vez habría algunos retrasos en la barra de cero. El resto de la historia estaría siempre disponible.
Sugerí una buena opción: almacenar en caché las series temporales necesarias en el momento de su plena disponibilidad. Y luego - obtener todos los datos necesarios de series temporales listas y siempre disponibles. Y sólo complementarlos con nuevos datos.
Esta es una mala variante, hay que repetir por completo la lógica de la construcción y la sincronización de las series de tiempo en el terminal - llegó un nuevo tick, la sincronización no había terminado... entonces un fallo de conexión
ZS: Sí, ¿y por qué hacerlo? - No sé cuántos en la vida, tengo un teléfono móvil, un coche, e incluso una cartera con uno solo, pero ¿muchos casos en la vida? - ¿Necesita un seguro? .... "Tres grabadoras, tres cámaras de cine extranjeras, tres pitilleras domésticas, chaqueta... de ante... Tres. Chaquetas" )))
Si se deniega el acceso a la serie temporal, significa que está sincronizada. Tienes que esperar hasta el siguiente tic.
Tienes razón! Pero es necesario para detener el programa MQL en cualquier lugar y salir de la terminal hasta la próxima garrapata ... Sugiero periódicamente algo así como en Delphi "Abort() o Halt()" - obtener un error de acceso a la serie de tiempo una vez - esun error crítico, que no tiene sentido para manejar muchas veces - de todos modos, hasta que el terminal no puede ajustar la interacción con el programa MQL "no sirve de nada" ))).
SZZ: Yo no creo este error (error de acceso a las series de tiempo) - es creado por la terminal, pero todos los programadores de MQL deberían estar preparados para depurar el error generado por la terminal... ( cuando el código consiste en un par de cientos de líneas ) es fácil de jugar, pero cuando el código es grande y es conveniente utilizar el acceso a las series de tiempo desde diferentes secciones del programa - y requiere 999 formas de salir de cualquier sección y no perder los cálculos anteriores... - Sí es posible, pero requiere un plan claro (algoritmo) por el que se escribirá el código fuente ... ¿Y si el código fuente se perfecciona añadiendo funciones (clases) ya hechas? - es decir, cada vez que tengas que averiguar qué hay dentro... una tarea que generalmente lleva mucho tiempo para los proyectos grandes para proporcionar todo, imho
Si un programa se ha construido durante 14 años, traducirlo por un nuevo método de diseño es más fácil que pegarse un tiro en el pie. Y la depuración de los múltiples enlaces también es difícil. La comprobación de la accesibilidad a los plazos da lugar a graves retrasos si no hay acceso. Estaría bien si se habilitaran lasconstrucciones gráficas automáticas. La reconstrucción en modo automático es un fenómeno poco frecuente. Es posible que ni siquiera note los retrasos aquí. Pero también en este caso, cuando se interrumpe el acceso a las series temporales, las construcciones gráficas salen a veces truncadas. Algunos de los elementos tienen tiempo de ser construidos y otros no... O bien, la filtración fractal trunca algunos tf.
***
Si un programa se ha creado a lo largo de 14 años, traducirlo con el nuevo método de diseño es más fácil que pegarse un tiro en el pie. Y la depuración de los múltiples enlaces también es difícil. La comprobación de la accesibilidad a los plazos da lugar a graves retrasos si no hay acceso. Estaría bien si se habilitaran las construcciones gráficas automáticas. La reconstrucción en modo automático es un fenómeno poco frecuente. Es posible que ni siquiera note los retrasos aquí.
Pero el problema es cuando el ajuste se realiza a través de la interfaz gráfica. El usuario pulsa el botón y... tiene que esperar al siguiente tick. O el usuario pulsa el botón varias veces hasta que se produce la respuesta deseada. ¿Cuál es la respuesta del usuario...? -***
Y en MT4 no existen estos problemas.
Te entiendo muy bien, así que decidí apoyar la discusión
Funciones iClose()...iXXX() para acceder a las series temporales - ¡genial!
Que sean funciones síncronas, es decir, el acceso a las series temporales será más largo pero garantizado a nivel de terminal. O los desarrolladores de U.V. deberían añadir la directiva del precompilador que dará un tick al programa MQL sólo si el terminal está preparado para acceder a los datos históricos (OHLC) - ningún tick si no.
....
pero el único propósito es deshacerse de las interminables comprobaciones de disponibilidad del gráfico OHLC, este problema se ha resuelto desde la aparición de MT5 sólo a nivel de comprobaciones dentro del programa MQL, es un proceso que consume tiempo y en mi opinión los usuarios esperan que el terminal reciba los datos de las series temporales sin problemas y garantizados en cualquier momento, en cualquier sección de código
esta es una mala opción, es necesario repetir completamente la lógica de la construcción y la sincronización de las series de tiempo en el terminal - a continuación, una nueva garrapata llegó, entonces la sincronización no terminó ... entonces un fallo de conexión
ZS: Sí, ¿y por qué hacerlo? - No sé cuántos en la vida, tengo un teléfono móvil, un coche, e incluso una cartera con uno solo, pero ¿muchos casos en la vida? - ¿Necesita un seguro? .... "Tres grabadoras, tres cámaras de cine extranjeras, tres pitilleras domésticas, chaqueta... de ante... Tres. Chaquetas" )))
Muy bien! Pero el programa MQL debe detener los cálculos en cualquier lugar y salir de la terminal hasta el siguiente tick... De vez en cuando sugiero algo como en Delphi "Abort() o Halt()" - tienes un error de acceso a las series de tiempo - es un error crítico, que no tiene sentido para procesar muchas veces - de todos modos, hasta que el terminal no establece la interacción con el programa MQL "no sirve de nada" ))).
SZZ: Yo no creo este error (error de acceso a las series de tiempo) - es creado por la terminal, pero todos los programadores de MQL deberían estar preparados para depurar el error generado por la terminal... ( cuando el código consiste en un par de cientos de líneas ) es fácil de jugar, pero cuando el código es grande y es conveniente utilizar el acceso a las series de tiempo desde diferentes secciones del programa - y requiere 999 formas de salir de cualquier sección y no perder los cálculos anteriores... - Sí es posible, pero requiere un plan claro (algoritmo) por el que se escribirá el código fuente ... ¿Y si el código fuente se perfecciona añadiendo funciones (clases) ya hechas? - es decir, cada vez que tengas que averiguar qué hay dentro... ...tarea que requiere mucho tiempo para los grandes proyectos, en mi opinión
Si el programa se ejecuta mediante un clic del ratón, no importa si hay un acceso o no lo hay: hay que reaccionar. Se puede escribir mucho sobre lo mal que se hace todo, pero en este caso es mejor tener una caché propia, desde la que se pueda acceder siempre a la demanda.
Imagínese el programa, que en lugar de dar algo en los datos históricos calculados a largo plazo por el clic del ratón, dice - ir a fumar - me da los datos actuales, que no necesita ahora, y reconstruir la serie de tiempo ...
Sea como sea, si tienes que conformarte con lo que tienes, es mejor dar lo que hay en la caché y luego reconstruirla después de desbloquear el acceso a las series temporales.