Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 298
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
¿Es mejor dedicar un poco más de tiempo al desarrollo y luego calcular siempre con rapidez, o desarrollar con rapidez y luego aguantar siempre cálculos lentos?
Si desarrollas rápidamente en R pero eres lento para calcular, ¿dónde quieres hacer el cálculo? ¿Rápido para desarrollar un supercoche que es lento de conducir? No necesitas un supercoche así.
En las tareas de investigación lo que prima es la velocidad de desarrollo. En lugar de una persona que escriba un código superrápido pero que pruebe una hipótesis al día, se contrata fácilmente a una persona que escriba un código lento y ejecute cálculos toda la noche, pero que tenga 20 hipótesis probadas al día siguiente.
Para la producción-implementación del modelo es más fácil contratar a otra persona con un pequeño salario, que reescribirá los modelos más prometedores en el lenguaje más rápido posible. Hay muchos programadores y la competencia es alta, pero los investigadores que pueden aportar algo nuevo son difíciles de encontrar :P
Es una práctica común. Busca puestos de trabajo como investigador cuantitativo y desarrollador cuantitativo. Los primeros suelen necesitar R/Python, los segundos suelen necesitar C++/Java.
En las tareas de investigación, lo que prima es la velocidad de desarrollo. En lugar de una persona que escriba un código superrápido, pero que compruebe 1 hipótesis al día, puedes contratar a una persona que escriba un código lento y lo ejecute toda la noche, pero que al día siguiente tenga 20 hipótesis comprobadas.
Para la implementación en producción del modelo, es más fácil contratar a otra persona por un pequeño salario, que reescribirá los modelos más prometedores en un lenguaje rápido. Hay muchos programadores, y la competencia es alta; pero los investigadores que pueden aportar algo nuevo son difíciles de encontrar :P
Es una práctica común. Busca puestos de trabajo como investigador cuantitativo y desarrollador cuantitativo. Los primeros normalmente tienen que saber R/Python, los segundos normalmente tienen que saber C++/Java.
¿No sería más fácil utilizar bibliotecas C++ listas y rápidas en lugar de utilizar las mismas pero lentas en R para un "desarrollo rápido"? Usted, y muchos otros aquí, hacen constantemente una sustitución de nociones. Del mismo modo, se puede "desarrollar rápidamente" en un entorno tipo C. ¿O no necesita conocimientos adecuados en minería de datos y estadística para trabajar en R? De la misma manera se necesitan los conocimientos para desarrollar en C. Entonces, ¿por qué hacer doble trabajo?
Y no sé a qué tipo de "práctica normal" te refieres, pero yo estoy acostumbrado a hacerlo bien a la primera y de una vez.
Durante mis prácticas de ingeniería, he visto a menudo a personas que, por alguna razón, pensaban que si utilizaban complejos de software súper fáciles de desarrollar, seguro que les iría bien... Pero no pudieron entender una cosa: necesitan otra cosa para que todo funcione bien: la grasa en la cabeza.
¿No es más fácil utilizar librerías C++, ya existentes y rápidas, en lugar de utilizar las mismas pero lentas en R para un "desarrollo rápido"? Usted, y muchos otros aquí, hacen constantemente una sustitución de nociones. Del mismo modo, se puede "desarrollar rápidamente" en un entorno tipo C.
La elección del lenguaje es un derecho y un asunto personal. Sobre las bibliotecas - por desgracia, para cualquier algoritmo moderno o inusual, tienes que implementar todo tú mismo. Por ejemplo, para calcular la "varianza de la bipotencia" (¿qué significa? :D) no he encontrado bibliotecas.
¿O no se necesitan conocimientos adecuados en minería de datos y estadística para trabajar en R?
No lo afirmo y no apoyo esta opinión.
Y no sé a qué tipo de "práctica común" te refieres, pero yo estoy acostumbrado a hacerlo bien a la primera y de una vez.
Durante mis prácticas de ingeniería, he visto a menudo a personas que, por alguna razón, pensaban que si utilizaban paquetes de software súper fáciles de desarrollar, seguro que les iría bien... Pero no podían entender una cosa: necesitaban algo más para que todo fuera bien: la grasa de sus cabezas.
Mi práctica en algunos proyectos con una complejidad de ## años-hombre, donde el 95% del código está escrito en R, muestra que las diferentes herramientas son buenas para diferentes tareas, a veces incluso lentas, siempre y cuando se utilicen para prototipos y no para producción. El uso de diferentes herramientas en diferentes etapas de desarrollo es una práctica común en la industria del desarrollo y se confirma por la necesidad de especialistas para diferentes trabajos. Los proyectos que mencioné se habrían vuelto mucho más complejos si se implementaran en un lenguaje tipo C, incluso por soldados universales que saben y pueden hacer todo y escribir la solución al problema de inmediato, sin ninguna fase de investigación.
Por lo tanto, me despido.
¿No es más fácil utilizar librerías C++, ya existentes y rápidas, en lugar de utilizar las mismas pero lentas en R para un "desarrollo rápido"?
Al hablar de R, siempre me he mantenido en una evaluación exhaustiva y sistemática de este "sistema de gráficos y estadísticas". el lenguaje algorítmico en sí no se menciona en absoluto en el título.
Una comparación frontal del rendimiento del código en R y como el anterior código en µl, u otro lenguaje de programación, en un ejemplo específico y local es completamente NO correcta, ya que el CT nunca consiste como se ha comentado anteriormente en una función de correlación, sino que siempre es un gran conjunto formado por código y llamadas a funciones. Dado que R tiene un enorme conjunto de funciones, el código suele tener un pequeño número de líneas (1000 líneas es mucho), pero un contenido muy amplio.
El programa en sí, que resuelve algún problema significativo, puede dividirse a grandes rasgos en dos partes:
En cuanto al punto 1, si hubiera que escribir cantidades importantes de código, el problema de la velocidad puede ser muy grave. Hay tres maneras de superarlo:
En cuanto al punto 2, el rendimiento es bastante diferente y dudo que sin un esfuerzo especial en el desarrollo habitual de µl-programa pueda superar a R en rendimiento.
Por ejemplo.
A primera vista, las operaciones con vectores y matrices en R son básicas. Una expresión de la forma a <- b*c es ejecutada por la biblioteca Intel. No hay bucles. Está al alcance de todo el mundo, no se requieren conocimientos ni esfuerzos adicionales. Cuando se desarrolla un programa μl, lo más probable es que se utilicen ciclos, aunque también es posible remitirse a la misma biblioteca (si el programa no es para el mercado), pero se requiere un nivel de conocimiento y esfuerzo bastante alto para lograr el mismo resultado.
Pero eso no es todo.
Si nos dirigimos a algoritmos de gran carga computacional, y éstos apelan a funciones de R, el propio desarrollador, enfrentado al problema del rendimiento, se ha preocupado de este problema y suele resolverlo en la fase de desarrollo. Esto suele resolverse escribiendo código C o recurriendo a bibliotecas C o Fortran. Además, estos algoritmos tienen entre sus parámetros la posibilidad de especificar el uso de muchos núcleos. Un desarrollador en R obtiene todo esto automáticamente sin esfuerzos. Uno puede concentrarse plenamente en la esencia de la CT, no en la técnica de aplicación. Es dudoso que el desarrollador de μl-programa pueda superar al desarrollador de funciones en R por la razón trivial - es necesario trabajar específicamente en el rendimiento, pero no en la esencia de la CT.
De todo lo escrito se desprende que una comparación correcta del rendimiento sería escribir el código real de TC en µl y el mismo código en µl+R (no hay órdenes comerciales en R) y comparar. Pero en todo su esplendor, ¿lo necesitamos?
¿Alguien ha probado a trabajar con gráficos de recurrencia? Puede leer sobre ello aquíhttps://habrahabr.ru/post/145805/, en particular para sustituir los MOs en lugar de los BPs crudos? podría funcionar como una opción
y más para leerhttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
Una idea para los que puedan ponerla en práctica. La visión artificial compara estas parcelas buscando la coincidencia de patrones. Como sustituto de la correlación inútil
Una idea para los que puedan ponerlo en práctica. Comparación de estas parcelas por parte de la máquina en busca de una coincidencia de patrones. Como sustituto de la correlación inútil.
Anteriormente, algunas ideas no podían ser probadas por la CT, ya que se veía obstaculizada por el bajo rendimiento de algunos algoritmos. En este caso, eso es exactamente lo que ocurrió: un algoritmo alternativo permitió en el optimizador explorar una idea que es tan antigua como el mundo, pero que no pudo ser calculada previamente en un tiempo razonable.
Cuando hay que calcular cientos de miles de millones de Pearson QC en patrones de unos pocos miles de longitud, la baja velocidad de una tarea aparentemente sencilla se convierte en un cuello de botella insuperable. Se podría empezar a decir que si un problema parece demasiado pesado desde el punto de vista computacional, se trata de un problema mal formulado y poco comprendido. Tal vez lo sea. Pero lo hecho, hecho está. Y siempre es interesante ver cómo otros implementan cosas similares.
Y si lo implementas en la GPU también, serás realmente valioso ))
Sin ponzi se puede encontrar el patrón más frecuente. Pero, ¿qué sentido tiene?
Bueno para una estrategia de patrón, por supuesto ) no necesariamente la más frecuente, puede haber muchas variantes
No es necesariamente el más frecuente para las estrategias de patrones, puede haber muchas variantes.
Esto es lo que no entiendo. El uso de datos patrón es útil cuando se comprimen datos con poca pérdida de información (varios medios). Pero, ¿qué tiene esto que ver con el TC?
La forma más fácil de hablar de este tema es utilizar el patrón más frecuente como ejemplo. No es una tarea difícil encontrarlo.
Aquí hay algún acertijo (patrón) que ocurre con más frecuencia. Su criterio de selección no es tan importante en este momento. Que el enigma esté ahí. ¿Cómo utilizarlo para comerciar?
Decir que si una historia externa coincide con una zagulina en el primer 80%, entonces los siguientes precios seguirán el mismo patrón que el 20% restante de la zagulina es una tontería.
Esto es lo que no entiendo. El uso de datos patrón es útil cuando se comprimen datos con poca pérdida de información (varios medios). Pero, ¿qué tiene esto que ver con el TC?
La forma más fácil de hablar de este tema es utilizar el patrón más frecuente como ejemplo. Encontrarlo no es una tarea difícil.
Aquí hay algún acertijo (patrón) que ocurre con más frecuencia. Su criterio de selección no es tan importante en este momento. Que el enigma esté ahí. ¿Cómo utilizarlo para comerciar?
Decir que si una historia externa coincide con una zagulina en el primer 80%, entonces los siguientes precios irán por el mismo camino que el 20% restante de la zagulina es un sinsentido.
¿Por qué crees que es una tontería? si el pronóstico se confirmará, sobre la misma historia, en una masa de casos