Aprendizaje automático en el trading: teoría, práctica, operaciones y más - página 297
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
apply(embed(pattern, length(signal)), 1, cor, y = signal, method = 'pearson')
Gracias. Me pregunto cuánto cuenta la R así. He medido el algoritmo de la biblia con una longitud de señal de 1.000.000 y un patrón de 100.000 - 1 segundo.
¡Un millón de veces más rápido! ¿Y qué? ¿Los sistemas de comercio miden como los procesadores?
¡Un millón de veces más rápido! ¿Y qué? ¿Los sistemas de comercio se miden como procesadores?
Tienes algún tipo de complejo.
No, no es un complejo.
μl y R son sistemas completamente diferentes y no superpuestos. ¿Y qué hay que comparar? Y no eres el único.
μl y R son sistemas completamente diferentes y no superpuestos. ¿Y qué hay que comparar? Y no eres el único.
Sólo me interesaba la velocidad de realización de una tarea estadística no rara en cualquiera de los idiomas.
R es el lenguaje estadístico más popular y hay muchos usuarios de él. Por eso se plantea aquí la cuestión de la comparación.
Interesa el algoritmo de aplicación y, en consecuencia, su eficacia. No importa en qué idioma esté escrito.
Sólo me interesaba la velocidad de ejecución de una tarea estadística no infrecuente en cualquiera de los lenguajes.
R es el lenguaje estadístico más popular y mucha gente aquí lo conoce. Por eso se plantea aquí la cuestión de la comparación.
Interesa el algoritmo de aplicación y, en consecuencia, su eficacia. No importa en qué idioma esté escrito.
MT es un terminal de comercio. Así que yo, aquí en este sitio y en este hilo, estoy discutiendo el desarrollo de la ST. Pero siempre encontramos a personas que discuten algunos trucos de programación que no tienen prácticamente ningún efecto en los resultados comerciales. La función de correlación en sí misma es útil en otros algoritmos.
Esta función se puede utilizar en los bloques de decisión de trading (al menos yo la utilizo) pero su velocidad de ejecución no juega ningún papel, porque el tiempo principal para el cálculo de una señal de trading está determinado por otros algoritmos computacionalmente complejos que no están presentes en mql en absoluto.
Eso es en la fase de ejecución.
Si tenemos en cuenta la fase de desarrollo del ST, R es principalmente superior a µl, ya que es un intérprete, lo que resulta muy útil en la fase en la que el algoritmo no está del todo claro y necesitamos probar muchas variantes, por ejemplo, para comparar correlaciones de pares de divisas. En R el momento de comprobar la correlación es un golpe en el teclado, con un par de líneas, incluyendo una formación muy útil de vectores iniciales.
A eso me refería, a que no tiene sentido comparar la velocidad de ejecución de estas funciones y en general de cualquier otra función implementada en mcl y en R.
PS.
Pero tu biblioteca me salvó de estudiar mcl5, gracias por ello.
MT es una terminal de comercio. En consecuencia, yo, aquí en este sitio y en este hilo, discuto el desarrollo de la ST. Pero siempre encontramos a personas que discuten algunos trucos de programación que no tienen prácticamente ningún efecto en los resultados comerciales. De hecho tu pregunta es la misma porque la propia función de correlación tiene sentido en otros algoritmos.
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ó al optimizador explorar una idea que es tan antigua como el mundo, pero que no podía 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 estas cosas.
¿Es mejor dedicar un poco más de tiempo al desarrollo, pero luego calcular siempre con rapidez, o desarrollar con rapidez y luego aguantar siempre un cálculo lento?
Si R es rápido para desarrollar pero lento para computar, entonces ¿dónde se computa? ¿Desarrollar rápidamente un superdeportivo que es lento? No necesitas un supercoche así.
Sólo me interesaba la velocidad de ejecución de una tarea estadística no infrecuente en cualquiera de los lenguajes.
R es el lenguaje estadístico más popular y mucha gente aquí lo conoce. Por eso se plantea aquí la cuestión de la comparación.
Interesa el algoritmo de aplicación y, en consecuencia, su eficacia. No importa en qué idioma esté escrito.
Bueno, en una señal de 1000000 de longitud y un patrón de 100000 de longitud es poco probable que esa implementación cuente en un tiempo razonable en absoluto, porque requeriría crear una matriz de tiempo de 900001x100000 :D Pero tomó menos de 30 segundos para escribirlo, y hasta cierto tamaño de tarea será bastante aplicable. Podríamos hacer lo mismo con fft/convolve, en cuyo caso tendríamos que escribir más código, pero sería igual de rápido que el código C.
En R es muy conveniente hacer prototipos de modelos complejos - este es su lado fuerte. El rendimiento del código es una cuestión de habilidades y experiencia:
1. Algunas construcciones y tipos de datos de R funcionan más rápido que otros (tipos mutables vs inmutables (lista vs entorno), for vs lapply/sapply/etc., S4 vs R6).
2. La facilidad de paralelismo en R para algunos problemas permite obtener una solución de código lento más rápido de lo que costaría escribir código rápido en otro lenguaje + cálculo.
3. las operaciones individuales en la lengua se realizan de forma universal, pero ineficiente. Si se implementan funciones pequeñas pero computacionalmente pesadas en C++, se pueden obtener tremendos resultados sin reducir la velocidad de desarrollo tanto como en el caso de escribir todo el código en un lenguaje tipo C. Por ejemplo, sumar elementos de la matriz en filas o columnas en R puede ser de 4 a 15 veces más rápido que rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).
Bueno, en una señal de 1000000 de longitud y un patrón de 100000 de longitud esa implementación difícilmente puede ser calculada en un tiempo razonable, ya que requeriría crear una matriz de tiempo de 900001x100000 :D Pero me tomó menos de 30 segundos escribirla y hasta cierto tamaño de tarea será bastante aplicable. Podríamos hacer lo mismo con fft/convolve, en cuyo caso necesitaríamos escribir más código, pero sería igual de rápido que el código C.
R es muy bueno en la creación de prototipos de modelos complejos, ese es su punto fuerte. La velocidad del código es una cuestión de habilidad y experiencia:
1. Algunas construcciones y tipos de datos de R son más rápidos que otros (tipos mutables vs inmutables (lista vs entorno), for vs lapply/sapply/etc., S4 vs R6).
2. La facilidad de paralelismo en R para algunos problemas permite obtener una solución de código lento más rápido de lo que costaría escribir código rápido en otro lenguaje + cálculo.
3. las operaciones individuales en la lengua se realizan de forma universal, pero ineficiente. Si se implementan funciones pequeñas pero computacionalmente pesadas en C++, se pueden obtener tremendos resultados sin reducir la velocidad de desarrollo tanto como en el caso de escribir todo el código en un lenguaje tipo C. Por ejemplo, sumar elementos de la matriz en filas o columnas en R puede ser de 4 a 15 veces más rápido que rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).