Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 2695

 
Maxim Dmitrievsky #:
¿Adónde vas?

Sólo estoy bromeando, siempre es divertido tener una pelea o una charla.

 
Evgeny Dyuka #:

Sólo estoy bromeando. Siempre es divertido tener una pelea o una charla.

Bueno, escribe un artículo mejor. No sé.
 
Sí objetivo normal, para escribir su propia herramienta para MO y, por supuesto, es muy diferente de la utilización de herramientas de terceros y la conexión con ellos, por supuesto, más compleja tarea global y arriesgado, pero bastante lógico. Si el retraso será de un par de años desde el inicio de la utilización de paquetes de terceros después de su despegue en la caja de arena metaquotes todo será normal. Y por supuesto la usabilidad del entorno de programación para los codificadores estará en el primer lugar.
 
Valeriy Yastremskiy #:
Sí objetivo normal, para escribir su propia herramienta para MO y, por supuesto, esto es muy diferente de la utilización de herramientas de terceros y la conexión con ellos, por supuesto, más compleja tarea global y arriesgado, pero bastante lógico. Si el retraso será de un par de años desde el inicio de la utilización de paquetes de terceros después de su despegue en la caja de arena metaquotes todo será normal. Y por supuesto la usabilidad del entorno de programación para los codificadores estará en primer lugar.

No veo nada logico.

Realmente no puedo entender por qué sufrir, esperar y meterse en la implementación MQL de algo que no existe todavía y en qué forma será desconocido, pero se ha hecho hace mucho tiempo y fresco y tiene una gran comunidad. ¿Qué haría falta para llegar al mercado? Y tal vez, probablemente, vender algo, si tienes suerte, pero no es seguro.

Y luego no ser capaz de moverse en algún lugar con él, como crypto, donde el dinero real es. Y donde servicios con bots de trading como 3commas o veles.finance te darán la oportunidad de ganar dinero con normalidad.

 
Maxim Dmitrievsky #:
Bueno, escribir un artículo mejor allí no sé

Aún así, me gustaría entender la razón por la que no existe un análogo de mt-R para python. Se trata de la posibilidad de lanzar un intérprete desde un programa mql5 con la capacidad de enviarle comandos e intercambiar datos en ambas direcciones. Esto es conveniente, por ejemplo, para probar rápidamente un modelo entrenado sin destilarlo en código mql5, y en general es una herramienta bastante flexible. Y parece ser exactamente lo que quiere un aficionado a "parlotear y parlotear".

 
Evgeny Dyuka #:

No veo qué tiene sentido.

Realmente no puedo entender por qué sufrir, esperar y profundizar en la implementación en MQL de algo que aún no existe y en qué forma será desconocido, pero se ha hecho hace mucho tiempo y fresco y tiene una gran comunidad. ¿Qué haría falta para llegar al mercado? Y tal vez, probablemente, para vender algo, si tienes suerte, pero no es seguro.

Y luego no ser capaz de moverse en algún lugar con él, como crypto, donde está el dinero real. Y donde servicios con bots de trading como 3commas o veles.finance te darán la oportunidad de ganar dinero con normalidad.

De nuevo, complejo, global y arriesgado. Y siempre existe el riesgo de no gustar en infraestructuras como servicios como mercancía. Pero este es al menos un camino comprensible. Tal vez, por supuesto, la negación de cinta adhesiva en algunos momentos de éxito de su necesidad es el mal, pero ciertamente no es el camino objetivo.

 
Aleksey Nikolayev #:

Aún así, me gustaría entender la razón por la que no existe un análogo de mt-R para python. Me refiero a la posibilidad de lanzar un intérprete desde un programa mql5 con la capacidad de enviarle comandos e intercambiar datos en ambas direcciones. Esto es conveniente, por ejemplo, para probar rápidamente un modelo entrenado sin destilarlo en código mql5, y en general es una herramienta bastante flexible. Y parece ser exactamente lo que quiere un aficionado a "parlotear y parlotear".

Probablemente debido a la prohibición de intercambio de arrays entre el programa mqlPy y el intérprete Py.
La misma religión será para R.

Para ser honesto, no entiendo el punto de la seguridad crítica que MQ está hablando.

Tal vez no se trata de seguridad, sino de la complicada api de Py para arrays.
Simplemente no se molestaron en hacerlo.
La api de numpy es realmente dolorosa allí.

Estoy atascado con matlab en general ))
Escribí un C-api dll para enviar comandos, todo se intercambia bastante rápido, dentro de la frecuencia del sistema.
Pero para el intercambio en el proceso de fondo se lanza el motor de matlab, y consume mucha memoria.
La única desventaja de matlab.
Para escritorio y chequeo rápido está bien.

 
Aleksey Nikolayev #:

Aún así, me gustaría entender la razón por la que no existe un análogo de mt-R para python. Me refiero a la posibilidad de lanzar un intérprete desde un programa mql5 con la capacidad de enviarle comandos e intercambiar datos en ambas direcciones. Esto es conveniente, por ejemplo, para probar rápidamente un modelo entrenado sin destilarlo en código mql5, y en general es una herramienta bastante flexible. Y parece ser exactamente lo que quiere un aficionado al "repiqueteo y el parloteo".

Se hizo un análogo de python api para R, algo allí no funcionó para subirlo a un mercado local como pypi, no sé del resto. El código en lenguajes interpretados es lento, probablemente no tenga mucho sentido, es decir, no habrá pruebas rápidas :)
 
Roman #:

Probablemente debido a la prohibición de intercambio de arrays, entre el programa mql5 y el intérprete Py.
La misma religión será para R.

Para ser honesto, no entiendo el punto de seguridad crítica del que hablan los MQ.

Tal vez no se trata de seguridad, sino de la complicada api de Py para arrays.
Y simplemente no se molestaron en hacerlo.

Así que se hace para R - de alguna manera vía dll, aunque no entré en detalles.

 
Aleksey Nikolayev #:

Así que está hecho para R - de alguna manera a través de un dll, aunque no entré en detalles.

Entendí que el discurso es sobre el nativo.
Y entonces sí, se puede golpear en cualquier lugar a través de dll.