Menos código, más acción... escribir un EA - página 2

 
Maxim Kuznetsov:

el estilo de caso de uso es fundamentalmente procedimental, ya que es el más común. Los usuarios potenciales(programadores novatos) escriben de esta manera.

Lo que quiero decir es que su estilo es procedimental en esencia. Es decir, es procesal tanto por dentro como por fuera, con los problemas que ello conlleva. A nivel de usuario, no se pueden revelar los detalles de la aplicación por una cuestión de principios. Y tienes una cosa muy específica en tu código a nivel de usuario:

double GetData(EA *ea,int id,int shift,double &data[])
{
#ifdef __MQL4__
   // для 4-ки всё просто - по идентификаторам серии и бара получить данные
   switch ((ENUM_SERIES)id) {
      case FAST_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,FAST_MA_PERIOD,0,FAST_MA_METHOD,FAST_MA_PRICE,shift);
      case SLOW_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,SLOW_MA_PERIOD,0,SLOW_MA_METHOD,SLOW_MA_PRICE,shift);
   }
   return EMPTY_VALUE;
#else
   ...
#endif
}

Macros de compilación condicional, llamadas a implementaciones específicas de funciones MA, etc., etc. Es decir, no OOP, no FP, sino este tipo de programación procedimental mate. Y como guinda del pastel: ea.Symbol, es decir, formalmente, sigue siendo OOP.

 
Maxim Kuznetsov:

Intentaré (o intentaré, si me interesa) hacer una base para los EA.

El resultado será tan inútil (para la mayoría de la gente) como todos los mencionados en el hilo.

porque enseguida tratas de escribir a tu manera y no bien. como los autores de todos los mencionados.

 
Vasiliy Sokolov:

Me refiero a que su estilo es de naturaleza procedimental. Es decir, es procedimental tanto interna como externamente, con todos los problemas que ello conlleva. A nivel de usuario, los detalles de la aplicación no pueden ser revelados en principio. Y tienes una cosa muy específica en tu código a nivel de usuario:

Macros de compilación condicional, llamadas a implementaciones específicas de funciones MA, etc., etc. Es decir, no OOP, no FP, sino este tipo de programación procedimental mate. Y como guinda del pastel: ea.Symbol, es decir, formalmente sigue siendo OOP.

Una vez más, el caso de uso está escrito desde el supuesto punto de vista de los usuarios potenciales.

Pero en una medida suficiente para poder proceder a la biblioteca sin tocar el caso de uso en sí.

Tenemos que utilizar la compilación condicional, porque tanto el 4 como el 5 están en el foro.


 
Maxim Kuznetsov:

Una vez más, el caso de uso está escrito desde la presunta perspectiva de los usuarios potenciales.

Para decirlo de nuevo: ¿dónde está el requisito de estilo de procedimiento para insertar llamadas de funciones específicas dependientes de la plataforma como iMA(...)?

Maxim Kuznetsov:

Pero en un volumen suficiente para poder pasar a la biblioteca sin tocar el caso de uso en sí.

¿Cómo podemos hacerlo cuando el caso de uso está lleno de llamadas específicas de funciones dependientes de la plataforma?

Maxim Kuznetsov:

Tienes que usar la compilación condicional porque hay tanto 4 como 5 en el foro.

¿Así que el "código universal" a nivel de caso de usuario ni siquiera puede ser independiente de la plataforma?

 
Maxim Kuznetsov:

...

Si hablamos de casos de usuario, el mandamiento número uno es que no hay implementaciones específicas a este nivel. Pero a nivel de caso de usuario ya tienes plena dependencia de: 1) la plataforma, 2) la API del terminal. Es decir, la aplicación propuesta es totalmente incoherente con el concepto declarado.

 
Vasiliy Sokolov:

Si hablamos de casos de usuario, el mandamiento número uno es que no hay implementaciones específicas a este nivel. A nivel de caso de usuario, ya se depende completamente de: 1) la plataforma, 2) la API del terminal. Es decir, la implementación sugerida no se corresponde en absoluto con el concepto establecido.

En general, los desarrolladores escriben en MQL, y para la API de los terminales de comercio MT4, MT5 :-) Por lo tanto, el uso de la terminal de la API es normal.

El caso de uso debe demostrar/hacer las cosas típicas del área. No basta con añadir un par de números, sino que hay que tener un propósito comprensible para el usuario, el que queremos conseguir. El objetivo mínimo posible de los Asesores Expertos es el trading :-) El Asesor Experto más sencillo que se me ocurre es el de operar con medias cruzadas. Se encuentra en su totalidad en el puesto de origen.

Por cierto, funciona. En este mismo momento en lugar de negociar funciones se están dibujando talones y marcas de verificación :-) Estoy escribiendo/depurando los datos. Tan pronto como la parte con datos, aunque crudos, pero listos para la discusión - lo publicaré


 
Maxim Kuznetsov:

Generalmente se escribe en MQL y API de los terminales de trading MT4,MT5 :-) por lo que referirse al terminal API es normal.

El caso de uso debe demostrar/hacer las cosas típicas del campo. No hay que limitarse a añadir un par de números, sino tener un objetivo comprensible para el usuario, el que queremos conseguir. El objetivo mínimo posible de los Asesores Expertos es el trading :-) El Asesor Experto más sencillo que se me ocurre es el de operar con medias cruzadas. Se encuentra en su totalidad en el puesto de origen

Y por la forma en que funciona. En este momento estoy escribiendo/depurando datos en lugar de operar con funciones y dibujar ticks :-). Tan pronto como parte con los datos, aunque en bruto, pero estará listo para el debate - Voy a publicar también

Lo escribes correctamente. Pero el usuario entiende mucho mejor ese pseudocódigo:

if(SMA(Close, 12) > SMA(Close, 24))
   BUY();
else
   SELL();

Otra cosa es que hacer que funcione de esta forma (procedimental, tomo nota) es muy difícil, pero aún es posible. Esto es lo que hay que intentar conseguir: que las instrucciones a nivel de usuario sean lo más sencillas y abstractas posible. Pero en su código, el usuario tiene que especificar macros de compilación condicional, funciones específicas para calcular promedios y otros detalles técnicos que simplemente no puede manejar.

 
Vasiliy Sokolov:

Para decirlo de nuevo: ¿dónde tiene el estilo procedimental un requisito para insertar llamadas a funciones específicas dependientes de la plataforma como iMA(...)?

¿Cómo de intocable, si el caso de uso está repleto de llamadas a funciones específicas dependientes de la plataforma?

¿Así que el "código universal" a nivel de caso de usuario ni siquiera puede ser independiente de la plataforma?

4/5 plataformas tienen diferentes API's, así es como funciona aquí.

No voy a escribir otra capa de compatibilidad para todo, ni una biblioteca universal. Por mucho que no quiera :-)

sólo la base de los EA.

 
Vasiliy Sokolov:

Bueno, lo escribes correctamente. Pero el usuario entiende mucho mejor ese pseudocódigo:

Otra cosa es que sea mucho más difícil hacerlo funcionar de esta forma concreta (procedimental, aviso), pero aun así es posible. Esto es lo que hay que intentar conseguir: que las instrucciones a nivel de usuario sean lo más sencillas y abstractas posible. Pero en su código, el usuario necesita especificar macros de compilación condicional, funciones específicas para calcular promedios y otros detalles técnicos que simplemente no puede manejar.

En principio, puedes usar una entrada como la que citaste dentro de GetData OnCrossSignal. Potencialmente, incluso puedes escribir guiones :-) Pero todo a su tiempo... El manejo de datos se construye como una mesa electrónica.

 
Maxim Kuznetsov:

4/5 plataformas tienen diferentes API's, así son las cosas.

No voy a escribir otra capa de compatibilidad para todo, ni una biblioteca universal. Por mucho que no quiera :-)

sólo la base de los EA.

Mira el código de Artem. Su código tiene una única API, que es independiente de la plataforma de destino. Por eso es extraño escuchar el argumento de que "funciona así".