En una aplicación de la OOP - página 2
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
Lo principal es cómo utilizarlo después. Para probar diferentes entradas, puede hacerlo en bloque por número de conjunto de entrada. Es decir, hay una colección de conjuntos de entrada. Si es conveniente, entonces como una matriz de funciones. Los más sencillos: compra o venta incondicional por mercado. O condicional)). Y luego ejecutaremos el optimizador y miraremos los diferentes conjuntos de entradas.
Sí, parece que hasta ahora, establecemos el número de la estrategia en los ajustes y optimizamos por número en el optimizador. Pero esto es por primera vez, he estado soñando con hacer la auto-optimización sobre la marcha durante mucho tiempo.
¿Cuál es el objetivo de esta autooptimización (función objetivo)?
El objetivo es evidente. En primer lugar, el optimizador en el probador no tiene el día actual, al menos en MT4 con seguridad. Y lo hago para MT4.
En segundo lugar, el mercado puede cambiar bruscamente durante el día, sin ninguna razón (noticias). Probablemente lo has notado, un piso lento... Entonces, de repente, como si se hubiera esparcido mostaza bajo la cola, empiezan a caer citas. O bien es un piso, o es un caos total.
Creo que podemos clasificar tales condiciones e incluir la modificación necesaria de la estrategia al definirlas. ¿Cómo hacerlo? No tengo suficientes agallas para crear una IA. Pero el método de optimización puede determinar indirectamente el estado.
Hasta el momento, estos son sólo pensamientos no probados.
Sí, parece que hasta ahora, en los ajustes establecemos el número de estrategias y optimizamos por números en el optimizador. Pero esto es por primera vez, desde hace mucho tiempo tengo el sueño de hacer la auto-optimización sobre la marcha.
Su cliente quiere envolver todas las estrategias que conoce en un experto, según tengo entendido. No podrá terminar esta tarea hasta que tenga una lista de estrategias. Sugiero que elaboremos juntos los TdR.
Si ADEMÁS de esta lista de estrategias tocas el tema de la autooptimización, entonces escríbele una red neuronal, no reinventes la rueda y no aturdas la mente de tu cliente con conocimientos de programación básica. Esto es exactamente lo que te pide.
¿Y puedo darle un ejemplo de "golpeo"?
Aquí tienes. Jerarquía de clases comerciales en la biblioteca estándar:
Implica que el módulo de gestión monetaria es un Asesor Experto. El Trailing Stop también es un Asesor Experto. El Asesor Experto incluye otros Asesores Expertos. Esta herencia incoherente resulta del hecho de que tanto el trailing stop como la gestión del dinero necesitan acceder a algunos datos y métodos privados de un Asesor Experto básico.
Por cierto, hay largas guirnaldas de herencia. Los CIndicadores utilizan el CIndicatorBuffer que a su vez llama a sus métodos superiores. Como resultado, un simple rastreo del valor del indicador se convierte en una tarea muy confusa. Después de tres llamadas recursivas, perdemos completamente el sentido de dónde viene algo.
Y esto es sólo un ejemplo de herencia pobre. De hecho, cualquier jerarquía de clases más o menos grande basada en la herencia casi siempre se vuelve incoherente, confusa y recursiva. Lo que dificulta enormemente la depuración y el desarrollo posterior.
Creemos que la profundidad de la herencia debería limitarse a 1-2 niveles. Además, el primer nivel debe heredar de la definición global y universal del CObject de nivel cero (todos son objetos) e implementar la entidad específica "Expert", "Indicador", "Trailing Stop". El segundo nivel debe implementar la aplicación específica de "Asesor Experto basado en MACD", "indicador SMA", "Trailing Stop", etc. Pero el uso del tercer nivel debe ser severamente castigado y perseguido.
En otras palabras, resulta que la clasificación es una herramienta verdaderamente valiosa sólo cuando lo es:
Su cliente quiere envolver todas las estrategias que conoce en un experto, según tengo entendido. No podrá terminar esta tarea hasta que tenga una lista de estrategias. Sugiero que elaboremos juntos los TdR.
Si ADEMÁS de esta lista de estrategias tocas el tema de la autooptimización, entonces escríbele una red neuronal, no reinventes la rueda y no aturdas la mente de tu cliente con conocimientos de programación básica. Esto es exactamente lo que te pide.
Aquí tienes. Jerarquía de clases comerciales en la biblioteca estándar:
Implica que el módulo de gestión monetaria es un Asesor Experto. El Trailing Stop también es un Asesor Experto. El Asesor Experto incluye otros Asesores Expertos. Esta herencia incoherente resulta del hecho de que tanto el trailing stop como la gestión del dinero necesitan acceder a algunos datos y métodos privados de un Asesor Experto básico.
Por cierto, hay largas guirnaldas de herencia. Los CIndicadores utilizan el CIndicatorBuffer que a su vez llama a sus métodos superiores. Como resultado, un simple rastreo del valor del indicador se convierte en una tarea muy confusa. Después de tres llamadas recursivas, perdemos completamente el sentido de dónde viene algo.
Y esto es sólo un ejemplo de herencia pobre. De hecho, cualquier jerarquía de clases más o menos grande basada en la herencia casi siempre se vuelve incoherente, confusa y recursiva. Lo que dificulta enormemente la depuración y el desarrollo posterior.
Creemos que la profundidad de la herencia debería limitarse a 1-2 niveles. Además, el primer nivel debe heredar de la definición global y universal del CObject de nivel cero (todos son objetos) e implementar la entidad específica "Expert", "Indicador", "Trailing Stop". El segundo nivel debe implementar la aplicación específica de "Asesor Experto basado en MACD", "indicador SMA", "Trailing Stop", etc. Pero el uso del tercer nivel debe ser severamente castigado y perseguido.
Ahora entiendo la idea. Por cierto, la forma simple que he implementado esto en mis robots de comercio como he señalado. Sólo los nombres son diferentes.
ZS: ¿En qué se basa ese gráfico? ¿Algo parecido a Doxygen?
Aquí tienes. Jerarquía de clases comerciales en la biblioteca estándar:
Implica que el módulo de gestión monetaria es un Asesor Experto. El Trailing Stop también es un Asesor Experto. El Asesor Experto incluye otros Asesores Expertos. Esta herencia incoherente resulta del hecho de que tanto el trailing stop como la gestión del dinero necesitan acceder a algunos datos y métodos privados de un Asesor Experto básico.
Por cierto, hay largas guirnaldas de herencia. Los CIndicadores utilizan el CIndicatorBuffer que a su vez llama a sus métodos superiores. Como resultado, un simple rastreo del valor del indicador se convierte en una tarea muy confusa. Después de tres llamadas recursivas, perdemos completamente el sentido de dónde viene algo.
Y esto es sólo un ejemplo de herencia pobre. De hecho, cualquier jerarquía de clases más o menos grande basada en la herencia casi siempre se vuelve incoherente, confusa y recursiva. Lo que dificulta enormemente la depuración y el desarrollo posterior.
Me parece que la profundidad de la herencia debería limitarse a 1-2 niveles. Además, el primer nivel debe heredar de la definición global y universal del CObject de nivel cero (todos son objetos) e implementar la entidad específica "Expert", "Indicador", "Trailing Stop". El segundo nivel debe implementar la aplicación específica de "Asesor Experto basado en MACD", "indicador SMA", "Trailing Stop", etc. Pero el uso del tercer nivel debe ser severamente castigado y perseguido.
En otras palabras, resulta que la clasificación es una herramienta verdaderamente valiosa sólo cuando lo es:
+ pensamientos muy ciertos.
ZS: ¿En qué consistió dicho gráfico? ¿Algo parecido a Doxygen?
Sí, ojalá ;) He trabajado sobre esto en SnagIt durante una hora. Lo hice especialmente para mi artículo.