Probador de guiones y asesores de MG4 - página 10
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
Yo no he dicho eso.
No he tocado este tema para nada y no pienso meterme en él.
Aparentemente, me pareció:
Y los stoplots y takeprofits integrados son en realidad virtuales y se lanzan para su ejecución en el mercado cuando llega el momento. Esta solución tiene un lado bueno: ahorra en CS (garantía, margen).
Piense en lo que ofrecen las nuevas funciones de acceso a los datos y en el motivo de ello.
MetaTrader 4 tiene una profundidad limitada del historial, marcos temporales separados y acceso directo a las barras de su símbolo a través de Open/High/Low/Close/Time[xxx]. Este acceso directo es muy caro de implementar en términos de recursos y coste de CPU. Considera que cada Asesor Experto tiene su propia copia local de estos datos para evitar conflictos con otros Asesores Expertos y con el propio terminal.
Cuando el número de símbolos crece (por ejemplo, en MT5 se pueden tener entre 5 000 y 10 000 símbolos), y utilizando el historial profundo de un minuto como base de todos los plazos, en principio ya no es posible utilizar los métodos de MT4. No hay suficiente memoria RAM, y copiar grandes trozos mata el rendimiento. Por eso MT5 ya no mantiene automáticamente una copia oculta y cara del gráfico para cada experto.
En su lugar, hemos pasado a funciones CopyXXX muy económicas en las que el desarrollador solicita exactamente al array local la cantidad de datos que necesita, no todo el gráfico disponible. A continuación viene el manejo de datos locales más rápido posible (en lugar del antiguo y bastante caro Open/High/Low/Close/Time[xxx]), además el autor puede almacenar en caché estos datos y utilizarlos con moderación en la siguiente llamada. El ahorro de memoria y CPU es enorme. Además, la propia plataforma es especialmente práctica para gestionar grandes bases de datos: el acceso a ellas es siempre a demanda (en lugar de un acceso directo no supervisado) y esto permite una gestión flexible de las cachés.
También hay que tener en cuenta que la simplicidad de las llamadas Open/High/Low/Close/Time[xxx] en MQL4 se limitaba al símbolo y al marco temporal actuales, y todos los demás datos para otros símbolos y marcos temporales se obtenían mediante las funciones iClose/iLow(...), lo que provocaba graves retrasos. La transición en MQL5 a un único modelo de función CopyXXX ha mejorado radicalmente la situación, permitiendo a los desarrolladores obtener los trozos de datos necesarios mediante una sola petición, y no realizar múltiples llamadas bloqueadas (piense en todos los bloqueos en cada una de las llamadas a iClose).
...
¿Qué le parece el rendimiento de CopyXXX?
En cuanto al ahorro de memoria, no hay duda. Pero es más caro llamar a CopyXXX por cada tick que copiar una vez una matriz de cotizaciones en un buffer y acceder a ella por un índice directo de tipo Rates[X]. Aquí tenemos un dilema de programación clásico: "Ahorrar memoria frente a ahorrar tiempo de CPU".
Nada menos que una MT5. Ahora dirígete a ti mismo la misma pregunta, sólo que sustituye una B por una A.
¡Ve a aprender lo que es el MERCADO! Comerciante, ya sabes....
¿Así que estás diciendo que MT4 puede, digamos, almacenar el historial de spreads o "saber" sobre los volúmenes reales (sin todas las muletas y otras soluciones totalmente inadecuadas)?
¿Está de acuerdo en que en el mercado real el diferencial no es claramente fijo? Ve y en el tester de MT4 intenta probar el EA en cotizaciones con spread variable, luego hablamos.
No me importa tanto el resto del mundo como los intereses del desarrollo de expertos con lógicas complejas. ;)
La solución de compromiso sería organizar las órdenes virtuales a nivel de MT5. Entonces habría tanto la red que alguien necesita como la vieja lógica de trabajar con órdenes.
¿Asumirás los riesgos de esa "visualización"?
En MT5, todos los que querían han utilizado durante mucho tiempo la solución de cobertura con operaciones en diferentes instrumentos con un alto grado de correlación.
Sí, esto puede requerir mucho más margen que en MT4, pero el sentido común dice que es correcto.
Por supuesto, nadie ha anulado el esquema "virtual" en este caso.
Entonces, ¿estás diciendo que MT4 puede, por ejemplo, almacenar el historial de spreads o "saber" sobre los volúmenes reales (sin todas las muletas y otras soluciones inadecuadas)?
¿Está de acuerdo en que en el mercado real el diferencial no es claramente fijo? Ve y en el tester de MT4 intenta probar el EA en cotizaciones con spreads cambiantes, luego hablamos.
¿Asumirás los riesgos de esa "visualización"?
En MT5, todos los que querían están utilizando una solución de cobertura mediante el uso de operaciones en diferentes instrumentos con un alto grado de correlación.
Gracias a Dios, existe MT4 por ahora. :) Puede utilizarlo en un instrumento si lo desea. Puedes utilizar diferentes instrumentos.
¿Cuáles son los riesgos?
¿Y el rendimiento de CopyXXX?
En cuanto al ahorro de memoria, no hay dudas. Pero es más caro llamar a CopyXXX por cada tick que copiar una vez una matriz de cotizaciones en un buffer y acceder a ella por un índice directo de tipo Rates[X]. Aquí tenemos un dilema de programación clásico: "Ahorrar memoria frente a ahorrar tiempo de CPU".
CopyXXX tiene la misma velocidad que las funciones iClose/iOpen/iXXXX. Sólo iXXX devuelve un elemento a la vez y CopyXXX devuelve muchos y por lo tanto es más eficiente y productivo.
Probablemente, no consideras que MT4 copia forzosamente _todo_ el historial del gráfico local en el entorno de mercado del EA local (caché) antes de que se inicie cada tick handler. Y esto es muy caro, aunque tenemos un método para actualizar económicamente esta información. La función especial RefreshRates en MQL4 provoca un refresco forzado de las cachés y del historial del gráfico local.
Llamar a CopyXXX es mucho más eficiente, y los desarrolladores disponen de un mecanismo muy preciso y exacto de almacenamiento en caché de los datos solicitados previamente. Por ejemplo, no es necesario volver a solicitar el historial profundo en cada tic, sino almacenar/escribirlo localmente y acceder a él lo más rápidamente posible.
Si comparamos los antiguos métodos de acceso "directo" (en realidad no es acceso directo) Open/High/Low/Close y el trabajo con el array local double local[xxxx], este último es muchas veces más rápido. Por lo tanto, es mejor copiarse a sí mismo localmente y luego tener un acceso local rápido a los datos consultados repetidamente.
Gracias a Dios hay una MT4 por ahora. :) Con él, puedes utilizar un instrumento a la vez. Puedes utilizar diferentes instrumentos.
¿Cuáles son los riesgos?
Al desarrollar/utilizar "plataformas de comercio" hay ciertos costes y riesgos, que alguien acaba asumiendo.
En cuanto a la "virtualización" en el software de otros desarrolladores
Esto es algo bueno, siempre y cuando todo se utilice para sí mismo y las personas que implementan la solución entiendan lo que están haciendo.
Los principales costes serán: el dinero invertido en el desarrollo del sistema, el dinero invertido en mantenerlo en funcionamiento y el tiempo invertido en la ejecución del proyecto.
Los principales riesgos: se gastará demasiado tiempo o dinero para poner en marcha un proyecto viable (el proyecto no será rentable), el proyecto no será eficaz en comparación con otras soluciones, se introducirán errores ocultos en el código o los algoritmos durante la ejecución del proyecto.
Sí, los bancos y otros agentes del mercado recurren a desarrollar su software con la funcionalidad necesaria, pero gastan una enorme cantidad de tiempo y recursos. Mientras tanto, asumen absolutamente todos los riesgos.
En cuanto al trabajo con MT5 (diferentes variantes utilizando MT5)
Aquí, por supuesto, MQ hizo la mayor parte del trabajo, pero también introdujo ciertas restricciones en la funcionalidad.
Los principales costes serán: el dinero gastado para mantener el rendimiento del sistema y el tiempo dedicado a la ejecución del proyecto.
Los principales riesgos: el proyecto no será eficiente en comparación con otras soluciones, habrá errores ocultos en el código o en los algoritmos a la hora de poner en marcha el proyecto, tendrá que supervisar constantemente el rendimiento de todo el sistema (protegerlo de problemas de software y hardware; supervisar la calidad de las comunicaciones, el suministro de energía, la seguridad de los datos, etc.).
Por supuesto, se puede pensar en una aplicación comercial (que permita a otras personas utilizarla), con ciertas limitaciones y advertencias.Me gustaría echar un vistazo a
He aquí un ejemplo en el que la simplicidad y la facilidad de uso de la POO a la hora de escribir programas sencillos es especialmente evidente.