Proyecto del asesor - página 6
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
En el mundo civilizado, las listas se aplican mediante...
Por qué no escribes una biblioteca civilizada en MQL, y luego hablamos. Llevamos años escuchando estos gritos, y cuando te pones a ello, empiezas a hacer bodrios.
MQ realmente cometió un error con las referencias en CObject. No deberían estar ahí. Y estas referencias se utilizan en contenedores muy específicos como CList. ¿Pero dónde no hay errores? ¿Las lenguas civilizadas, dices? Lea la crítica de Richter sobre lo que piensa de Object C# y los métodos que no debería contener. Entonces, porque Richter tiene razón, ¿debemos negarnos a usar C#? No tiene sentido. Así que deja de amontonarte aquí y vete de una vez a tu selva procesal.
Pues sí, no se pueden poner objetos constantes en una lista.
Sin embargo, yo utilizo constantemente la funcionalidad de CObject, y ninguna de las críticas no ofrecía nada ni siquiera similar a los objetos de la Biblioteca Estándar arrays y listas.
"La forma en que se deben hacer las cosas" es el grito de todos. Pero para sugerir algo, de repente, no hay nada.
Incluso los participantes que realmente ofrecen diferentes soluciones de software - no ofrecen un reemplazo para el CObject - más a menudo no lo utilizan en absoluto, menos a menudo utilizan su funcionalidad, sin prestar atención a la "implementación a través de un lugar". Y esto significa que la implementación es bastante buena.
Si estuviera mal, hace tiempo que se habría sugerido su sustitución.
Normalmente se utiliza el CObject nativo cuando todo lo demás se basa también en la biblioteca estándar. En particular, los que comparten activamente sus fuentes, tienden a unificar, reducir el código autoescrito y reducir el número de bibliotecas propias para facilitar la vida a los usuarios externos. Pero cada uno decide por sí mismo si codifica para sí mismo o para la conveniencia de los demás.
Sin embargo, supongo que mucha gente utiliza sus propias soluciones (como yo), simplemente no ven la necesidad de ofrecerlas a los demás. Pero en general creo que sería mejor que hubiera algún estándar basado en algunas librerías conocidas, como MFC. Por eso no entiendo muy bien a MQ, por qué han tenido que reinventar su propia rueda (además de muy polémica), en lugar de portar una solución ya hecha. Sin embargo, lo mismo puede decirse del propio lenguaje MQL )))
Pero en principio, no estoy obligado a rechazar de CObject, sólo hice mi comentario crítico en respuesta a la frase, que alguien debe utilizar CMyCobject cuando hay un CObject muy fresco de MQ :)
Escribe una biblioteca civilizada en MQL, y luego hablaremos. Llevas años gritando, pero cuando te pones a ello, empiezas a hacer bodrios.
Bueno, tengo mis propias bibliotecas. ¿De qué querías hablar?
Me he hecho un lío con las referencias en CObject MQ. No deben estar allí. Y estas referencias se utilizan en contenedores muy específicos como CList. ¿Pero dónde no hay errores? ¿Las lenguas civilizadas, dices? Lea la crítica de Richter sobre lo que piensa de Object C# y los métodos que no debería contener. Entonces, porque Richter tiene razón, ¿debemos negarnos a usar C#? No tiene sentido. Así que deja de amontonarte aquí y vete de una vez a tu selva procesal.
No seas arrogante y grosero, no me dirijo a ti personalmente.
Sobre lo de "meter la pata con los enlaces", pues sí, curioso, después de que ya he pintado todo lo que hay. Aunque antes has babeado literalmente sobre CObject, que es tan grande, y que incluso los punteros no se inicializan ahí por defecto (al menos deberías haber estudiado antes el código fuente de tu lenguaje). De todos modos, no le veo ningún sentido a seguir echando pestes de ti aquí.
Pero estoy de acuerdo, no siempre es necesario utilizar la POO.
Digamos que tengo la clase CDataProvider:pulic CDataProviderI - proveedor de datos, que proporciona Expert Advisor con series de tiempo, indicadores, datos de la terminal y del entorno. En un Asesor Experto, puede haber muchos TSs - cada uno de ellos recibiría punteros a series de tiempo e indicadores del proveedor de datos (cada TS no necesitaría crear series de tiempo - el proveedor de datos proporcionaría punteros a las series de tiempo necesarias si ya existen, y sólo crearía series de tiempo, que no han sido creadas todavía).
Cuando necesite recibir un indicador del proveedor de datos, rellene la estructura de descripción del indicador y, a continuación, solicite un indicador al proveedor que apunte a esta estructura.
En consecuencia, cada indicador dentro del proveedor de datos debe ser capaz de identificar su estructura (el proveedor de datos "conoce" sólo la clase base abstracta de la estructura) y de acuerdo con ella crear el objeto indicador listo, que será creado por el proveedor de datos.
Pero no sería razonable iniciar este proyecto sólo para comprobar una nueva idea de un indicador. Como resultado, para estos nuevos indicadores todo es "a mano", sin ninguna OOP. Sin embargo, si veo que un indicador es útil para los Asesores Expertos - está escrito "correctamente" - con soporte OOP completo, y la creación dentro de un proveedor de datos.
Cuando probé todos los indicadores en MT4 hace unos 15 años para la idoneidad para el comercio en el modo de orden inverso, encontré sólo 1 que permite obtener beneficios en el diario. la mayoría de los indicadores se basan en los indicadores incorporados, es por eso que los resultados del comercio son bajos casi todos ellos. Creo que la primera tarea de cualquier comerciante es estudiar el mercado para la precisión de la predicción o la rentabilidad de un patrón.
con respeto.
El objetivo de todo este circo, es confundir y dirigir en la dirección equivocada, lejos del beneficio.
Bueno, has respondido a tu propia pregunta de por qué deberías usar CObject, en lugar de una bicicleta autoescrita. Esto es necesario para hacer la vida más fácil no sólo para los demás, sino principalmente para ti mismo, porque las palabras "unificación", "reducir el código auto-escrito", "reducir el número de sus propias bibliotecas" - esto es lo que cada desarrollador debe esforzarse. Este es el santo grial del programador.
Por supuesto, la biblioteca estándar es obsoleta. El lenguaje ahora permite hacer genéricos, y las interfaces están llegando. Pero la vieja biblioteca funciona y es una buena unificación, y como dicen lo mejor es enemigo de lo bueno. Como no existe lo perfecto y lo mejor hay que usar lo bueno.
Sobre lo de "meter la pata con los enlaces"... bueno, sí, es curioso, después de haber escrito ya todo sobre ello. Aunque antes te has "cagado" literalmente en CObject afirmando que es tan genial, y que incluso los punteros no se inicializan ahí por defecto (para empezar deberías estudiar el lenguaje fuente). En general, no veo el sentido de lanzar cuentas ante ti.
Aquí nadie se arrastrará ante ti. Créeme, el conocimiento "oculto" que nos has "revelado" a todos aquí es conocido por muchos desde hace tiempo. Ni siquiera voy a discutir sobre la inicialización de los enlaces. Sabes que formalmente tienes razón, así que tratas de restregarme lo mismo: lee las matemáticas, aprende lo que NULL, etc., etc. Pero no tienes que enseñarme. Eres genial. Lo tienes todo. Entonces, ¿por qué nos tiras cuentas? Ve a tu biblioteca. A ver si se hace un 0,5% más rápido.
Los indicadores Fractales y Pinbars también se utilizan a menudo. Es una solución maravillosa para muchos sistemas de trading que utilizan los mismos indicadores en sus operaciones. pero no son adecuados para las pruebas, es por eso que tienen que ser escritos por su cuenta.
hace 15 años yo estaba probando todos los indicadores en MT4 para la idoneidad de operar en el modo de posición inversa y encontré sólo uno que era rentable sobre una base diaria.
No, sólo hay que acertar con la esencia del indicador. Un indicador no es un Grial ya hecho, sino sólo una expresión conveniente de algunas peculiaridades del movimiento de los precios. Por lo tanto, no debemos tratarlos como "la fuente final de la señal", sino sólo como una "característica de la señal" y utilizarlos como un complejo. Y en este caso - muchos indicadores comienzan a ser necesarios en la mayoría de las pruebas. En concreto, el ATR, por ejemplo, ya estoy pensando en incluirlo de serie en una plantilla de Expert Advisor porque lo uso prácticamente en todas partes. Las MA también son indicadores necesarios con bastante frecuencia. Fractales, indicadores de barras...
...
Pero, estoy de acuerdo, no es ni mucho menos necesario utilizar OOP.
Digamos que tengo una clase CDataProvider:pulic CDataProviderI - un proveedor de datos, que proporciona a los expertos con series de tiempo, indicadores, datos de la terminal y el medio ambiente. En un Asesor Experto, puede haber muchos TSs - cada uno de ellos recibiría punteros a series de tiempo e indicadores del proveedor de datos (cada TS no necesitaría crear series de tiempo - el proveedor de datos proporcionaría punteros a las series de tiempo necesarias si ya existen, y sólo crearía series de tiempo, que no han sido creadas todavía).
Cuando necesite obtener un indicador del proveedor de datos, rellene la estructura de descripción del indicador y, a continuación, solicite un indicador al proveedor que apunte a esta estructura.
En consecuencia, cada indicador dentro del proveedor de datos debe ser capaz de identificar su estructura (el proveedor de datos "conoce" sólo la clase base abstracta de la estructura) y de acuerdo con ella crear el objeto indicador listo, que será creado por el proveedor de datos.
Pero no sería razonable iniciar un proyecto de este tipo sólo para comprobar una nueva idea de un indicador. Como resultado, para estos nuevos indicadores todo es "a mano", sin ninguna OOP. Sin embargo, si veo que un indicador es útil para los Asesores Expertos, está escrito "correctamente" - con soporte OOP completo y creación dentro de un dataprovider.
P.D.
Por cierto, en el caso de los indicadores y el proveedor de datos vemos la ventaja de la herencia de la virtualización. Tenemos la interfaz básica de los parámetros del indicador CIndicatorParametersI; el descendiente de esta interfaz son los parámetros reales del indicador necesario. Al solicitar el indicador, declaramos estos parámetros y pasamos al proveedor de datos un puntero a la interfaz abstracta. Así, el propio proveedor de datos ni siquiera sabe qué indicador se solicita: se define en una función, en la que se crea el indicador según el nuevo tipo. Y qué parámetros exactamente se pasaron - sólo este indicador creado lo sabe, extrae los parámetros requeridos del objeto pasado.
El truco es que casi en todas partes dentro del dataprovider hay una clase básica simple de parámetros (o indicadores) - sólo las funciones más simples y más comunes de las interfaces básicas están disponibles para el dataprovider. Esto simplifica la modificación del código (cuando es necesario), y no crea la tentación de "manipular" el código de los indicadores del proveedor de datos. Si se quiere cambiar un indicador, se hace sólo dentro del indicador, el proveedor de datos es sólo un almacén de indicadores, lo máximo que puede hacer es crear un nuevo indicador.
Creo que lo estás complicando demasiado. El proveedor de fechas es el propio MetaTrader. Es decir, el proveedor de fechas no es realmente necesario, sólo necesita una interfaz conveniente para trabajar con los datos. Por ejemplo, en mi Libera, sólo tienes que escribir el precio de apertura de la última barra:
El objeto WS siempre está ahí y siempre está a mano y funcionando. El modo en que lo hace está oculto entre bastidores. Eso es todo el acceso a los datos:)
s.o.p. La POO debe reducir la complejidad de uso del sistema, no aumentarla. Si admite que tiene que construir un jardín para una simple comprobación, significa que tiene algo mal en su arquitectura con el proveedor. Es decir, has programado algo que no siempre quieres usar.No, sólo hay que acertar con la esencia del indicador. Un indicador no es un Grial ya hecho, sino sólo una expresión conveniente de algunas peculiaridades del movimiento de los precios. Por lo tanto, no debemos tratarlos como "la fuente final de la señal", sino sólo como una "característica de la señal" y utilizarlos como un complejo. Y en este caso - muchos indicadores comienzan a ser necesarios en la mayoría de las pruebas. En concreto, el ATR, por ejemplo, ya estoy pensando en estandarizarlo en una plantilla de Expert Advisor porque lo uso prácticamente en todas partes. Las MA también son indicadores necesarios con bastante frecuencia. Fractales, indicadores de barras...
Me refería a trabajar en el modo "siempre en el mercado" basado en la señal del indicador de inversión, y de nuevo, hace 15 años, ahora mi visión del mercado ha cambiado ligeramente.
con respeto.
Creo que lo estás complicando más de lo necesario. El proveedor de datos es el propio MetaTrader. Es decir, no se necesita realmente un proveedor de fechas, sino una interfaz fácil de usar para trabajar con los datos. Por ejemplo, en mi Libera, sólo tienes que escribir el precio de apertura de la última barra:
El objeto WS siempre está ahí y siempre está a mano y funcionando. El modo en que lo hace está oculto entre bastidores. Eso es todo el acceso a los datos:)
s.w. La POO debe reducir la complejidad del uso del sistema, no aumentarla. Y si tú mismo admites que necesitas construir un huerto para una simple comprobación, significa que algo falla en la arquitectura de tu ISP. Es decir, has programado algo que no siempre quieres utilizar.Su (vamos a ser "usted") entrada "WS.Open[0];" difiere muy poco de mi entrada "m_tcMainContainer.Open(0)"
Sospecho que debe haber alguna acción preliminar en la inicialización del objeto WS.
En mi caso deberíamos llamar a la función bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer).
En cada parte de un Asesor Experto (en el generador de entradas, en los controladores de trailing y exit, es decir, en los objetos que pueden realizar acciones de trading) tengo el objeto "Timeseries Container" - de hecho, es un puntero a las timeseries OHLCSTVtVr con opciones de servicio adicionales.
En un Asesor Experto puede haber muchos contenedores de diferentes símbolos y diferentes marcos temporales. La ideología del proveedor de datos permite no duplicarlos. Ya que en realidad - todas las series de tiempo se almacenan en él, y los contenedores - sólo apuntan a los necesarios.
No veo mucha diferencia - según tengo entendido, WS (WareStore, probablemente ?) sigue siendo el mismo mi dataprovider. Es que mi dataprovider también concentra el resto de los datos - indicadores, símbolos (objetos CSymbolInfo), terminal (objeto CTerminalInfo), que también tiene una colección de gráficos. En cada refresco, la serie de tiempo se actualiza (según sea necesario) - aquí la ideología es cercana a la de la Biblioteca Estándar.
Si consideramos a MT4-5 como proveedor de datos, y nuestra clase se utiliza sólo para proporcionar acceso - entonces resulta que de acuerdo con su referencia al precio de apertura debemos llamar a la función CopyOpen() para un valor - esto me parece poco razonable.
Dar acceso global completo a todas las variables en cualquier lugar del programa también me parece extremadamente irrazonable, por el contrario, trato de tener acceso sólo a aquellas estructuras y datos, que son necesarios para esta acción en cada lugar del programa. Todo lo demás debe ser inaccesible. La ideología del proveedor de datos me permite controlar este acceso.
No lo considero un indicador, muestra la volatilidad media del mercado en un determinado periodo de tiempo, no sirve como señal de entrada (se puede aplicar como filtro, nada más).
Me refería a trabajar en el modo "siempre en el mercado" basado en la señal del indicador de inversión, y de nuevo, hace 15 años, ahora mi visión del mercado ha cambiado ligeramente.
Respetuosamente.
¿Qué quieres decir con que "el ATR no cuenta como indicador"?
¿Y cómo es que "no es adecuado como señal de entrada"? Y soy un tonto, uso la entrada de "desglose de la volatilidad" utilizando sólo este indicador...?
Sospecho que tienes tu propia y específica comprensión de la esencia de los indicadores... Para mí, un indicador es un objeto que puede producir algún valor variable, dependiendo del tiempo. De hecho, incluso un gráfico ordinario de velas del precio es también un indicador. Pero para ti es otra cosa... En consecuencia, nuestra comprensión es diferente.