Haciendo un sistema de trading en Python para MT. - página 9

 
Resultados interesantes para el Sber. ¿Podría compararlos con los resultados del terminal? Y, yo los ejecutaría de verdad, al menos un lote...
 
Yuriy Asaulenko:

Si puedes escribir todo en MQL, realmente no necesitas nada más.

No puedo ni quiero escribir y entrar en detalles de algoritmos que ya están escritos, practicados y disponibles. No quiero utilizarlos directamente, en lugar de reescribirlos o adaptarlos a MQL. Por cierto, este es el concepto principal de la POO.

La POO por sí sola no es suficiente para no entrar en detalles, necesitamos modelos de componentes de intercambio e interacción entre programas, como OLE->ActiveX->DCOM->.Net, de lo contrario siempre tendrás que maniobrar entre lenguajes y bibliotecas.
 
Ivan Negreshniy:
Para no entrar, la POO por sí sola no es suficiente, necesitamos modelos de componentes de intercambio e interacción entre programas, como OLE->ActiveX->DCOM->.Net, de lo contrario siempre tendremos que maniobrar entre lenguajes y librerías.

Supongo que Python, con sus extensas bibliotecas, no necesitará todo esto en un futuro próximo. Salvo en lo que respecta a la comunicación de los terminales, pero esta cuestión se ha resuelto hace tiempo e incluso de varias maneras.

 
Yuriy Asaulenko:

Sinceramente, este Python es molesto, junto con sus clases. Aquí tienes un pequeño fragmento de una de las funciones:

¿Cuenta cuántas veces se repite la palabra "yo" en este pequeño trozo de código ?

Y todo el tiempo y en todas partes, en cada línea varias veces. Esta tontería se repetirá en todas las funciones (métodos) de cualquier clase todo el tiempo.

sí... Sí, python es bueno sólo como "pegamento", para el scripting de unas pocas a un par de docenas de líneas, entonces hay una clara ventaja sobre C++\Java, pero es más costoso implementar OOP multinivel en python, incluso a nivel de conveniencia, la velocidad de tales bibliotecas está fuera de la cuestión. Python es divertido para mostrar los principios en las presentaciones, etc. Es muy "limpio" en apariencia de la personalización, que, obviamente, deben ser escritos en otros idiomas, pero para escribir algo serio, con hilos y GUI en Python es un verdadero fastidio

 
Yuriy Asaulenko:

El probador propio es más interesante porque puedes tener un control total del proceso, lo que es absolutamente esencial para las pruebas. Y el probador en sí es una construcción muy sencilla.

No veo el sentido de financiar nada, ya que lo hago sólo para mí.

Lo hago sólo para mí. El probador no tiene un algoritmo complicado, pero hay un montón de lugares en los que puedo cometer un error. Pero, por supuesto, utilizar los desarrollos de otra persona no puede ser menos arriesgado, al menos por las mismas razones, y tal vez por algunas otras relacionadas con las particularidades de "quién se beneficia de ello".

 
pantural:

hum hum... Sí, python es bueno sólo como "pegamento", para scripts de unas pocas a un par de docenas de líneas, entonces hay una clara ventaja sobre C++/Java, pero es caro hacer OOP multicapa en python, incluso a nivel de conveniencia, la velocidad de tales bibliotecas está fuera de la cuestión. Python es divertido para mostrar los principios en las presentaciones, etc. Es muy "limpio" en apariencia de la personalización, que claramente debe ser escrito en otros idiomas, pero para escribir algo serio, con hilos y GUI en Python es un verdadero dolor.

¿Por qué "whew..."? Todo está bien allí en Python, y la velocidad también está bien. Incluso los bucles de 55k funcionan bien, en la penúltima versión. De hecho, las librerías de Python son rápidas, mientras que el propio Python sirve sobre todo para enlazar palabras en una frase.

En general, hablar rápido - lento no tiene sentido en sí mismo. Si es rápido, ¿para qué sirve exactamente? Si es lenta, entonces de forma similar.

 
Yuriy Asaulenko:

¿Qué es eso de "sibilante..."? Todo está bien allí en Python, y con velocidad también. Incluso los bucles de 55k funcionan bien, en la penúltima versión. De hecho, las librerías de Python son rápidas, mientras que el propio Python sirve sobre todo para enlazar palabras en una frase.

En general, hablar rápido - lento no tiene sentido en sí mismo. Si es rápido, ¿para qué sirve exactamente? Si es lento, de forma similar.

55k son migajas, hay que contar miles de millones, por lo que el probador nativo de python no funcionará, tendrás que escribir e importar la libu en los pluses, y python es sólo para llamar y configurar, pues puede ser 100 veces más lento.

y "ejem" era sobre "self" y 100500 métodos y atributos __***__, IMHO hacen un código mucho más complicado que incluso en los pluses, y si hablamos de hilos, eventos y GUI, todo no es mejor que con los pluses, más bien lo contrario, todo este "duck typing" y cosas así empiezan a doler, hay que tener mucho en cuenta, recordar muchas cosas
 
pantural:

55k son migajas, hay que contar miles de millones, y por lo tanto un probador nativo de python no funcionará, tendrás que escribir e importar la librería en plusses, y python sólo llama y configura, porque puede ser 100 veces más lento.

y "ejem" era sobre los métodos "self" y 100500 __***__, IMHO hacen un código mucho más complicado que incluso con los pluses, y si hablamos de hilos, eventos y GUI, todo no es mejor que con los pluses, más bien lo contrario, todo este "duck typing" y cosas así, al contrario, solo empieza a doler, hay que tener en cuenta muchas cosas

No sé por qué necesito miles de millones)). El probador - No tengo ninguna queja, hasta ahora todo es rápido, 3 meses pasan en un momento, y no necesito más).

Con todo lo demás, creo que estoy de acuerdo, en los pluses es más divertido escribir. Pero no se puede modelar en las ventajas. Resulta que: primero modelamos algo en un software, y luego lo portamos a los pluses, escribimos todo tipo de interfaces para las librerías... es un verdadero engorro.

Y en Python todo en un solo paquete, y un entorno de simulación normal + todas las librerías necesarias, normalmente en C++. Para la estrategia es suficientemente rápido - 15-30 ms no es un retraso para mí. Eventualmente puedes reescribir las secciones críticas en C, como hacen en la NASA. Si es que hay alguna, claro.

Y nada es perfecto en absoluto).

 
Yuriy Asaulenko:

No sé por qué necesito miles de millones)). Probador - No tengo ninguna queja, hasta ahora todo es rápido, 3 meses se desliza en un momento, y no necesito más).

Con todo lo demás, creo que estoy de acuerdo, en los pluses es más divertido escribir. Pero no se puede modelar en las ventajas. Resulta que: primero modelamos algo en un software, y luego lo portamos a los pluses, escribimos todo tipo de interfaces para las librerías... es un verdadero engorro.

Y en Python todo en un solo paquete, y un entorno de simulación normal + todas las librerías necesarias, normalmente en C++. Para la estrategia es suficientemente rápido - 15-30 ms no es un retraso para mí. Eventualmente puedes reescribir las secciones críticas en C, como hacen en la NASA. Si es que hay alguna, claro.

Y nada es perfecto en absoluto).

En el contexto de la optimización son miles de millones cuando se ejecutan cientos o incluso miles de pruebas en cientos de miles de barras de minutos. No somos nuestros enemigos esperando durante horas para obtener un par de índices genéticos simples para un año de minutos, se debe hacer en segundos, mientras que en Python se tardará mucho más tiempo, al igual que en las cajas negras con la ralentización deliberada de los cálculos.

Y python en general es una herramienta muy atractiva en el contexto adecuado, aunque en mi opinión su popularidad actual es un fenómeno pasajero, es algo así como la moda de las redes sociales y los gadgets de Apple, hay una conexión con el brillo exterior y el minimalismo en ejemplos muy sencillos, y también los estudiantes que inflan sus valoraciones.


PS Por cierto, ¿por qué crees que tu probador funciona correctamente? El probador es algo complicado....

 
pantural:

Miles de millones en el contexto de la optimización cuando la prueba se ejecuta cientos o incluso miles de veces en cientos de miles de barras de minutos. No somos nuestros enemigos esperando durante horas para un par de índices genéticos simples para un año de minutos, se debe hacer en cuestión de segundos, pero en Python se llevará mucho más tiempo, así como en las cajas negras con la ralentización deliberada de los cálculos.

No estoy en el negocio de la optimización y todo tipo de coincidencia de parámetros. Mi metodología es diferente, pero necesito un entorno similar a MatLab, R, SciLab, etc. Python es igual de bueno.

Tampoco necesito 10^6 barras. Para todo - unos 6, máximo 9 meses en minutos es suficiente. Ahora la prueba es de 3 meses -2,5 m, aunque el sistema aún no es tan complicado.

El más largo es aprender ML, pero no hay nada mejor que Python, y aquí es sólo como un lenguaje de scripting. Digamos que la respuesta de una red neuronal entrenada de 5 capas, unas 60 neuronas, es de 3-5 ms.

Hasta ahora, no veo ninguna prueba real del alarmismo.