Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc. - 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
No te creas que me hago el listo, pero mira de nuevo esta arquitectura de escribir una CT de combate. No hay retroalimentación.
Hay posiciones virtuales y hay un entorno comercial real que se ajusta a la virtualidad.
En ese caso, ni siquiera importa si la compensación está en la plataforma o en otro sistema contable.
Creo que es una estructura muy interesante, sobre todo para las estrategias de alta velocidad que no se pueden comprobar en el probador habitual.
Sólo que no está muy claro lo del "sincronizador inteligente". Probablemente se refieran a un copiador adaptativo de órdenes comerciales cuya tarea, si entiendo bien, es ajustar la rentabilidad virtual / rentabilidad de la estrategia y el estado actual del mercado - liquidez, velocidad de ejecución, etc.
En general, sería bueno tener tal probador y sincronizador no monolíticamente construido en el Asesor Experto, sino como un módulo externo separado.
En este caso, se puede conectar cualquier Asesor Experto o varios e incluso utilizar selectivamente las señales más adecuadas.
Me pregunto si esto es realista usando sólo MQL...
Así que es un módulo independiente en términos de lógica.
Por ejemplo, el servicio de Señales es un módulo independiente, no relacionado con el ST de ninguna manera:
Simplemente traduce las posiciones virtuales de origen (son virtuales para usted) en su entorno de negociación.
Curiosamente (no de forma óptima), por supuesto, pero se traduce.
Se trata de un módulo independiente en términos de lógica.
Por ejemplo, el servicio de Señales es un módulo independiente, no relacionado con el ST de ninguna manera:
Simplemente traduce las posiciones virtuales de origen (son virtuales para usted) en su entorno de negociación.
Curiosamente (no de forma óptima), por supuesto, pero se traduce.
Resulta que hay un traductor de Google que traduce torcido pero que sirve si no necesitas entenderlo, pero si necesitas entenderlo con precisión - aprende el idioma).
Me conformaría con una opción intermedia - un traductor personal de alta calidad (módulo), cuando la traducción es buena y no hay necesidad de escribir código en cada EA.
La comprensión de cómo estructurar un programa viene con la experiencia. Cada uno tiene experiencias diferentes, por lo que el orden y las reglas de estructuración serán únicas. Además, estas normas cambiarán con el tiempo, es decir, lo que parecía una estructura ideal hace un par de años, hoy puede no resistir ni la más ligera crítica.
La estructura de los programas en MQL es un tema aparte, porque en esencia es un DSL, controlado por eventos desde el terminal (aunque se han dado pasos enormes para acercarlo a los lenguajes de propósito general). Imho, para la descripción de las estrategias de negociación la mejor manera es una máquina de estado, y ya había algunos artículos al respecto aquí. De hecho, la estructura degenera en un gran caso con un montón de encludes para cada caso.
Haciendo abstracción de las tareas comerciales, suelo asignar una parte central, que no sabe nada de los detalles de la interacción con el usuario. Su propósito es proporcionar una forma de llenarse de datos, resolver el problema basado en los datos recibidos y emitir el resultado. El núcleo puede consistir físicamente en varios archivos, pero todos ellos deben estar conectados lógicamente y proporcionar fuera sólo métodos de recepción de datos y métodos de devolución de datos y nada más. La analogía más sencilla es una picadora de carne.
La segunda cosa que creo que es importante es localizar las partes que se van a cambiar (o las partes que podrían cambiarse) y separarlas en una abstracción separada. Con este enfoque, podemos cambiar sin problemas entre diferentes implementaciones del mecanismo (por ejemplo, al cambiar el mecanismo de apertura de posiciones, podemos virtualizar el comercio). Las diferentes implementaciones se almacenan convenientemente en una carpeta separada con un nombre genérico.
La estructura del proyecto se asemejará a un árbol con su tronco (Core) formado por diferentes subsistemas (Subsystems) y ramas de comportamiento cambiante (Behaviour) que parten de él. Y junto a él habrá unos prismáticos (Reporting, GUI) para mirar el árbol desde el ángulo necesario y un hacha y una motosierra (Actions, GUI) para proporcionarnos la interacción necesaria con el árbol.
Máquinas de estado sencillas al servicio del desarrollador
Máquinas de estado sencillas al servicio del desarrollador
Poner al menos un ejemplo aproximado para aplicar a nuestras realidades.
La implementación de cualquier estrategia es esencialmente una máquina de estado.
Entiendo. Pedí un ejemplo de tal máquina a la luz del artículo sobre la charabra.
Ah, vale. Había un artículo en el que el tipo hacía un "análogo" de una máquina de estado. Y él impulsaba esta tecnología como una innovación de programación de vanguardia).
Pero no recuerdo ningún artículo sustancial sobre las máquinas de estado aquí. No lo recuerdo aquí.
Poner al menos un ejemplo aproximado aplicado a nuestras realidades.
Jajaja, me recuerda a "cuál será tu prueba".
Acabo de buscar en Google "state machine", he escogido el contenido que más me ha gustado y lo he subido aquí.
No se demuestra nada, ni se refuta nada. Un artículo interesante.
En general, estoy en contra de los dogmas. Si una persona lo usa, no significa que le sirva a otra.
Pero cuando leo el código de otra persona a menudo me encuentro con analogías con las máquinas de estado. Sólo una observación.