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

 
mytarmailS:

Hay un montón de palabras, pero la esencia ....., tal vez no captura, como para mí el hombre sólo se quejó un poco))

La cuestión es que no hay que enfrascarse en "golosinas" en forma de R, Matlab, python etc. De todas formas, después todo se convertirá a C++, y este proceso es casi independiente, el código R no es un prototipo de C++. La gente se engancha a todo tipo de RAD y luego se muerde los codos, les llevará 2-3 años deshacerse de los malos hábitos, si una persona se da cuenta de que se metió en un callejón sin salida, por supuesto, a menudo no lo hace.

 
Gianni:

En este caso, la cuestión no es si hay un patrón en el mercado, es por la propia naturaleza del mercado

¿Hay alguna prueba de que existan patrones? ¿Y por qué entonces Buffett no busca estas regularidades, sino que utiliza un análisis fundamental? Y Soros dice que "el mercado es el caos y sólo el caos"... Y Greenspan no pudo identificar patrones en sus muchos años de investigación
 
es probable que existan ineficiencias limitadas por la liquidez o por el tiempo y que el mercado las elimine en cuanto se hagan públicas
 
ivanivan_11:
deben existir ineficiencias limitadas por la liquidez o por el tiempo
¿Y en qué se diferencia la ineficacia de un patrón? Porque aparece aleatoriamente en el tiempo y desaparece de forma igualmente aleatoria una vez que ha agotado su liquidez
 
A100:
¿En qué se diferencia la ineficacia de la regularidad? En el sentido de que aparece aleatoriamente en el tiempo y desaparece de forma igualmente aleatoria una vez que ha agotado su liquidez

Bueno, en mi opinión, la ineficacia es más a corto plazo.

la regularidad es algo así como los ciclos de mercado decenales, hay una caída, hay una subida. o patrones estacionales, y el resto es ineficiencia

 
J.B:

La cuestión es que no hay que meterse en todo tipo de "chucherías" en forma de R, Matlab, python y demás. De todas formas, luego todo se convertirá a C++, y este proceso es casi independiente, el código en R no es un prototipo de C++. La gente se hace adicta a varios RAD y luego se muerde los codos, les llevará 2-3 años deshacerse de sus malos hábitos, si una persona se da cuenta de que se metió en un callejón sin salida, pero a menudo no lo hace.

Hay exactamente una línea sobre R en el artículo:

A veces, aunque pocas veces, uno tiene ganas de tirar de Matlab o R ;-) Hay un consejo: ir directamente al médico.

Debo añadir que esta frase se refiere a la neurona profunda y no a R en general. El problema es que R es un intérprete y por tanto la velocidad de los cálculos matemáticos es un poco más lenta que en lenguajes de programación compilados como C++ o Java.
Para un alto rendimiento en R necesitamos escribir la librería C++ con interfaz a R, esto se hace en la mayoría de los casos. O, lógicamente, podrías crear una neurona directamente en C++, sin R. Trabajar con datos en c++ es más incómodo que en R, pero aparentemente este enfoque es bastante aceptable.
En general, R en producción es bueno para el procesamiento de datos, no se necesita un médico.

Crear una neurona en R puro sigue siendo una mauvais ton.

 
J.B:

La cuestión es que no hay que meterse en todo tipo de "chucherías" en forma de R, Matlab, python y demás. De todas formas, luego todo se convertirá en C++, y este proceso es casi independiente, el código en R no es un prototipo de C++. La gente se engancha a varias RAD emergentes y luego se muerde los codos, les llevará 2-3 años deshacerse de los malos hábitos, si una persona se da cuenta de que se metió en un callejón sin salida, por supuesto, a menudo no lo hace.

El 99% de la gente de este foro son investigadores que no tienen una buena estrategia de trabajo y la están buscando, los que la tienen, son más propensos a observar en silencio este hilo ...

Entonces, si yo, como investigador, quisiera probar una red neuronal en el mercado, ¿qué es mejor? Pasar medio año para averiguarlo por mí mismo y escribir la red en C++ y entender que no funciona, o probar esta idea en "pops" R usando la solución ya preparada y entender que tampoco funciona, pero se tarda menos de 30 minutos, ese es el plus de todos los "pops" R, No me refiero a la producción - la producción es cuando sabes exactamente lo que estás haciendo y tienes TdR y demás, y cuando estás investigando - este es un método visceral, sólo estás buscando, y si escribes soluciones ya hechas para cada investigación, perderás mucho tiempo - ¡me ahorré mucho tiempo con R!)

No intento promocionar R ni decir que es el mejor, puedes escribir en Pascal si te gusta, pero en esta situación y en este contexto, cuando estás investigando el mercado, R es la mejor solución en este momento. Pero cuando tengas una producción entonces tendrás que pensar...

 
mytarmailS:

El 99% de la gente de este foro son investigadores, los que no tienen una buena estrategia de trabajo y la están buscando, los que la tienen, más bien miran en silencio este hilo...

Entonces, si yo, como investigador, quisiera probar una red neuronal en el mercado, ¿qué es mejor? Pasar medio año para averiguarlo por mí mismo y escribir la red en C++ y entender que no funciona, o probar esta idea en "pops" R usando la solución ya preparada y entender que tampoco funciona, pero se tarda menos de 30 minutos, ese es el plus de todos los "pops" R, No me refiero a la producción - la producción es cuando sabes exactamente lo que estás haciendo y tienes TdR y demás, y cuando estás investigando - este es un método visceral, sólo estás buscando, y si escribes soluciones ya hechas para cada investigación, te perderás la vida).

No intento promocionar R ni decir que es el mejor, puedes escribir en Pascal si te gusta, pero en esta situación y en este contexto, cuando estás investigando el mercado, R es la mejor solución en este momento. Y cuando haya una producción, ya puedes pensar en ella...

Depende del tipo de investigación, si estás haciendo una investigación para tu trabajo de fin de curso, entonces sí, es mucho más fácil tomar una función, ejecutarla y obtener un informe estándar con buenos gráficos, sin preguntas.

Si las investigaciones del ingeniero quant, en la oficina financiera, donde toman el dinero del mercado, no sólo debido a las comisiones, o tecnologías cercanas al mercado, entonces la situación es diferente. Por regla general, en las oficinas adecuadas, se tarda unos 5 años en construir su infraestructura de comercio, donde hay un 95% de todas las herramientas necesarias, que están convenientemente envueltas y se pueden utilizar no mucho más complicado que en R, todo es transparente y disponible para la edición y el baile de pandereta. En este nivel, un quant piensa en el sistema de abstracciones que le proporciona su infraestructura comercial y cuanto más lejos llega este sistema de abstracciones, más único y no reducible a partes comunes. La mayoría de las ideas de negociación son variaciones de la estructura de las abstracciones de alto nivel de la infraestructura de negociación, que en principio no se pueden comprobar en R o en Matlab, porque no se trata de alimentar MLP con estocásticos con diferentes ventanas.

A veces puedo usar R(Matlab, matemáticas) como una especie de calculadora avanzada cuando necesito dibujar alguna función exótica o algo similar de tipo estudiantil para probar, pero está lejos de buscar estrategias de trading. Pero si escribes código de más de 100 líneas en R con lógica de estrategia, etc., poco a poco desarrollas el hábito de pensar en términos de R , lo que luego perjudica fuertemente, ya que programar con "cubos", etc., ese es el peligro. este es el peligro. Los problemas estándar se resuelven rápidamente, los complejos suelen llegar a un punto muerto, porque no pueden aproximarse con las herramientas disponibles o requieren un baile de pandereta mucho más enrevesado que en los pluses. El codificador empieza a pensar como un diseñador creyendo que está programando y entonces se limita a variar los parámetros de una herramienta ya preparada y cuando hay que programarla, resulta muy poco amigable e inconveniente.

 
J.B:

Depende del tipo de investigación, si se trata de una investigación de un estudiante para aprobar un trabajo trimestral, entonces sí, es mucho más fácil coger una función de la estantería, ejecutarla y obtener un informe estándar además con bonitos gráficos, no hay preguntas.

Si las investigaciones del ingeniero quant, en la oficina financiera, donde toman el dinero del mercado, no sólo debido a las comisiones, o tecnologías cercanas al mercado, entonces la situación es diferente. Por regla general, en las oficinas adecuadas, se tarda unos 5 años en construir su infraestructura de comercio, donde hay un 95% de todas las herramientas necesarias, que están convenientemente envueltas y se pueden utilizar no mucho más complicado que en R, todo es transparente y disponible para la edición y el baile de pandereta. En este nivel, un quant piensa en el sistema de abstracciones que le proporciona su infraestructura comercial y cuanto más lejos llega este sistema de abstracciones, más único y no reducible a partes comunes. La mayoría de las ideas de negociación son variaciones de la estructura de las abstracciones de alto nivel de la infraestructura de negociación, que en principio no se pueden comprobar en R o en Matlab, porque no se trata de alimentar MLP con estocásticos con diferentes ventanas.

A veces puedo usar R(Matlab, matemáticas) como una especie de calculadora avanzada cuando necesito dibujar alguna función exótica o algo similar de tipo estudiantil para probar, pero está lejos de buscar estrategias de trading. Pero si escribes código de más de 100 líneas en R con lógica de estrategia, etc., poco a poco desarrollas el hábito de pensar en términos de R , que luego perjudica fuertemente, ya que programar con "cubos", etc., ese es el peligro. este es el peligro. Los problemas estándar se resuelven rápidamente, los complejos suelen llegar a un punto muerto, porque no pueden aproximarse con las herramientas disponibles o requieren un baile de pandereta mucho más enrevesado que en los pluses. El codificador empieza a pensar como un diseñador creyendo que está programando cuando sólo está variando los parámetros de las herramientas ya hechas y cuando necesitas programarlo, resulta muy poco amigable e inconveniente.

Probablemente la opinión más sensata y objetiva de R que he visto últimamente. Los viejos fans de la R, los que cojas de este foro al menos, todos piensan igual, incluso puedes confundirlos entre ellos si no te fijas en sus nicks, todos piensan igual.
 

No es la primera vez que este foro impone un debate sobre "¿Qué idioma es mejor?".

Personalmente, cada vez recuerdo que MT4/5 son herramientas de TRADING, no de programación.

¿Qué vas a programar en C o en R? De todos modos, ¿quién necesita este proceso? Se necesita dinero, y éste resulta del bloque de toma de decisiones sobre las posiciones. Hay un montón de herramientas preparadas en R para este propósito, y el problema no está en desarrollar estas herramientas, sino en usarlas. No hay que programar nada en R - hay mucho más de lo que una persona puede dominar, ¿no es posible entender una idea tan simple?

Y por último sobre el tema de que alguien aquí creará un código más eficiente en C.

Sólo la gente que no tiene ni idea de lo que hay que programar puede hacer esas declaraciones. Si consiguen captar el objeto de la programación, descubrirán que tendrán que competir con las bibliotecas Fortran y C, los biblios de aritmética matricial y todo eso en el modo de cargar todos los núcleos del ordenador.

¡Apoyos C! Siéntese e intente entender aunque sea un poco R, no con R, sino con los paquetes de R, por ejemplo, los que aparecen en el shell caret, que incluye hasta 200 paquetes (varios miles de funciones), relevantes para el comercio. Y entonces, con suerte, se te quitarán las ganas de demostrar públicamente tu ignorancia.

Razón de la queja: