Tema interesante para muchos: las novedades de MetaTrader 4 y MQL4 - grandes cambios en camino - página 9
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
Ahora que hemos tocado el mercado, me gustaría escuchar opiniones sobre un tema...
Según la filosofía de MQL5, los indicadores deben contar y los EAs deben operar.
Pero Market vende soluciones ya hechas, como se dice, todo en uno.
¿Quizás habría que mejorar el compilador para que los indicadores se almacenen en los EAs como recursos?
De lo contrario, tenemos que transferir el código del indicador al Asesor Experto donde no tiene un entorno adecuado. Una vez más, el esquema "indicador de indicador" hace que sea todo un epopeya para transferir el código al Asesor Experto.
Estoy de acuerdo,
Creo que sería útil añadir una pestaña para el Mercado ahora - ARCHIVOS, donde se pueden poner juegos, instrucciones, etc,
Creo que sería útil añadir una pestaña - ARCHIVOS en la que se puedan almacenar conjuntos, instrucciones y demás.
¿Podemos perfeccionar el compilador para que almacene los indicadores en los EA como recursos?
De lo contrario, tenemos que trasladar el código de un indicador a un Asesor Experto, donde no tiene un entorno adecuado. De nuevo, el esquema "indicador de indicador" hace que sea toda una epopeya trasladar el código al Asesor Experto.
Ver MetaTrader 5 Client Terminal build 730 el 24 de noviembre de 2012
8. MQL5: Se ha añadido soporte para almacenar indicadores en recursos EX5. Al mismo tiempo, los indicadores de recursos no podrán trabajar con sus propios recursos.
Véase el comunicado de prensa MetaTrader 5 Client Terminal build 730 del 24 de noviembre de 2012
Esto es exactamente lo que hago. Y ya he escrito clases que pueden pasar al Asesor Experto el historial personalizado (en lugar del historial real del servidor). Pero el Asesor Experto no debería usar funciones del terminal directamente para implementar completamente mi idea. Digamos que el mismo OrderSend(). Debería funcionar sólo a través de un "wrapper", cuyo papel puede ser maravillosamente realizado por la Biblioteca Estándar. Escribimos clases derivadas, las metemos en el Asesor Experto, y voilá - ahora funciona con datos históricos. Si el Asesor Experto utiliza las funciones del terminal directamente, no podrá utilizar el historial.
Bueno, quizás se deba a mi largo trabajo con la librería MFC, que me ha gustado mucho y con la que encuentro muchos paralelismos. Estoy seguro de que los desarrolladores de la Biblioteca Estándar también conocen muy bien MFC.
La principal ventaja de la Librería Estándar es el buen soporte de la ideología OOP, que permite pasar al Asesor Experto un historial personalizado para que funcione correctamente sin ninguna modificación.
¿Puedo preguntar qué es lo que no te gusta de la biblioteca estándar (bueno, además de la desventaja obvia: "demasiado perezoso para aprender")?
No es una desventaja, conozco muy bien a SB, y este conocimiento me permite comprender lo engorroso e ineficiente que es todo.
En lugar de enviar un pedido, se inicia un abuelo por un abuelo y un abuelo por un nabo.
Pero la principal desventaja (según Trade) es que no hay ningún control de la ejecución. Simplemente envían una orden al servidor y dejan que la hierba crezca. Pero envolvieron a Send de 10 maneras, como para todas las ocasiones, pero los casos resultaron ser 100.
En cuanto a la ideología: heredar por más de 2 generaciones es un error, más allá se pierde tanto la comprensión como la flexibilidad.
La mayoría de las clases (tienes razón) no fueron inventadas, simplemente fueron reinventadas desde MFC, pero eso no es una desventaja, para qué reinventar la rueda.
Pero creo que el principal inconveniente es que no pueden confiar en él).
He escrito tanto con como sin SB. Sin ella se consigue más rapidez y transparencia. Es demasiado versátil, por lo que es lento en las curvas.
En Delphi, por ejemplo, existe el concepto de proyecto, que implica una compilación conjunta. Y la división de los programas en 3 tipos es un poco dudosa en general, porque el compilador, en teoría, puede determinar por sí mismo lo que hace el programa, pero como va tan lejos que los indicadores sólo comercian a la fuerza, y para la EA es necesario implementar el código en el interior, entonces sólo podemos esperar que el corazón de los desarrolladores se derrita alguna vez y permitan hacer proyectos).
...secundado,
Creo que sería útil añadir una pestaña de ARCHIVOS para que el mercado almacene juegos, instrucciones y demás, por ejemplo,
aunque la pestaña de Discusión lo permite, pero sigue sin ser lo mismo.
Ver MetaTrader 5 Client Terminal build 730 del 24 de noviembre de 2012
Genial, cómo se me ha pasado esto, aaah son las construcciones previas a las vacaciones.
¿Significa el cruce en su puesto que ya pueden?
Esa es precisamente la desventaja, conozco muy bien SB, y este conocimiento me permite comprender lo engorroso e ineficiente que es todo.
Gracias por su exhaustiva respuesta. No tengo ninguna objeción categórica a ninguna de sus afirmaciones. Sólo... algunas observaciones...
En lugar de enviar una orden, abuelo por abuelo, abuelo por nabo.
Pero eso es lo que da flexibilidad al sistema, y es lo que nos permite enviar el historial personalizado y la emulación del servidor al EA. Si los pedidos se enviaran directamente a través de OrderSend() - tendríamos que escribir esto "La abuela es para el abuelo, el abuelo para la abuela"... No está claro cuál es mejor...
Pero la principal desventaja (según Comercio) es que no hay ningún control de la aplicación. Si se "choca" con un pedido a un servidor y no se le da importancia. Pero envolvieron a Send de 10 maneras, como para todas las ocasiones, pero los casos resultaron ser 100.
No tengo la suficiente experiencia en esto, sólo puedo teorizar. Yo mismo analizo los códigos de devolución, pero tengo muy poca experiencia. Estoy de acuerdo en que no hay suficiente control de la ejecución en el propio SB.
En cuanto a la ideología: considero que heredar más de 2 generaciones es un error, además se pierde tanto la comprensión como la flexibilidad.
Sí, efectivamente, una herencia demasiado profunda es muy perjudicial para la comprensión. Pero en cuanto a la flexibilidad, me resulta difícil estar de acuerdo. Tengo un montón de casos de herencia de 4-5 generaciones, y no parece causar ningún problema. Pero, puedo estar de acuerdo en que este es mi caso, para otros esta profundidad de la herencia puede ser un obstáculo importante.
Pero la principal desventaja creo que es que no se puede confiar en ella, escribes algo en ella y se rehace :)
Sí, estoy completamente de acuerdo con eso.
He escrito tanto con como sin SB. Escribí con SB, pero sin él conseguí ser más rápido y transparente. Es demasiado versátil, por lo que es torpe en las curvas.
Me gustó SB por su capacidad de crear una plantilla de TC y, posteriormente, conectar a ella sólo las clases de objetos que describen las entradas, el mantenimiento y las salidas. Me temo que sin SB tal ideología llevaría a la creación de lo mismo, sólo que SB propio.
Sobre lo de "más rápido y transparente", me parece que esa ideología es buena cuando se trata de cualquier TS en su conjunto. Sin embargo, me parece que esto es un grave error de algotrading. El TS debe ser visto sólo como un conjunto de "cubos" - un conjunto de generadores de entrada, determinante de entrada TP-SL, determinante de entrada lote, controlador de arrastre y así sucesivamente... Esta ideología permite obtener muy rápidamente cientos de variantes de TS diferentes, donde nosotros sólo tenemos unas pocas "más rápidas y transparentes".
Por ejemplo, habiendo escrito cinco TS diferentes sin plantilla - para escribir la sexta tendremos que hacerlo todo de nuevo, incluso utilizando partes de estos cinco sistemas. Habiendo escrito la plantilla - introduciremos estos cinco sistemas en ella sólo en partes, y como resultado tendremos hasta cinco generadores de entrada, filtros de entrada, determinantes TP-SL, etc. Combinándolas obtenemos fácilmente un centenar de ST, entre las que podemos elegir las más estables y rentables.
Por lo tanto, en mi opinión, la lentitud del SB es realmente un "arma de doble filo", y su aplicación o no aplicación debe decidirse en cada caso individualmente.
Súper, cómo se me pasó eso, ahhhhh son las construcciones previas al año nuevo.
¿La tachadura en tu post significa que ya pueden?
Genial, cómo se me pasó eso, ahhh son las construcciones previas al año nuevo.
Se ha discutido aquí: https://www.mql5.com/ru/forum/3409#comment_408123