Discusión sobre el artículo "Distribuciones Estadísticas en MQL5: tomando lo mejor de R" - página 7
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
Estoy hablando de R, pero mi habilidad es veri pequeña)) ¿alguien puede comprobar si el código es correcto?
Si el código es correcto, ¿puede comprobar el punto de referencia?
El código es incorrecto.
Has medido el tiempo de compilación de la función, no su ejecución:
La función cmpfun compila el cuerpo de un cierre y devuelve un nuevo cierre con los mismos formales y el cuerpo sustituido por la expresión del cuerpo compilada.
Prueba del error:
> library(microbenchmark) > library(compiler) > n <- 2000 > k <- seq(0,n,by=20) > qqq<- function(xx) { a <- dbinom(k, n, pi/10, log = TRUE) } > res <- microbenchmark(cmpfun(qqq)) > a Ошибка: объект 'a' не найденSi la función qqq se hubiera ejecutado durante el benchmark, el objeto a habría recibido los datos calculados. Pero resultó que el objeto ni siquiera se creó.
Como resultado, el benchmark contó el tiempo de compilación en lugar del tiempo de ejecución. En mi código, todo es correcto - el benchmark cuenta el tiempo de ejecución real y el objeto a se crea con los datos correctos.
Y sí, la compilación es un proceso bastante costoso: se muestra en milisegundos en lugar de microsegundos.
Y una broma aparte, cómo anulaste la función del sistema q() - salir - en tu ejemplo.
No había manera de salir de R :)
Me refiero a que el compilador mql ya conoce todos los parámetros de entrada en tiempo de compilación. Basta con que lo calcule todo durante la compilación, y al llamar al script, simplemente devuelve el resultado precalculado. Vi algunos artículos en el hub donde comparaban compiladores de c++, y a juzgar por el análisis del código ensamblador, esto es exactamente lo que ocurre allí.
Sí, puede que lo esté utilizando activamente. Aquí hay algunos ejemplos: https://www.mql5.com/ru/forum/58241.
Pero en este caso no va a funcionar - es necesario contar en su totalidad debido a la complejidad, el llenado de bucles y matrices.
si el código es correcto, ¿puedes comprobar el benchmark?
Tienes que sustituirres <- microbenchmark (cmpfun ( q) ) por res <- microbenchmark(q())). Pero las librerías previamente compiladas no se recompilarán en bytecode, obtuve los mismos resultados.
qqq<- function(xx) { a <- dbinom(k, n, pi/10, log = TRUE) }"a" en este caso será una variable local, inaccesible fuera de la propia función de todos modos. Pero se puede hacer de esta manera
a <<- dbinom(k, n, pi/10, log = TRUE)
entonces será una variable global.
Pero en este caso no va a funcionar - que necesita para contar en su totalidad debido a la complejidad, el bucle y la matriz de llenado.
Ya veo, la velocidad de ejecución es excelente entonces
Por cierto, no cuesta prácticamente nada interpretar la llamada primitiva a <- dbinom(k, n, pi/10, log = TRUE) con una caída directa en el núcleo de R con ejecución nativa(dbinom está en r.dll).
Así que tratar de compilar esta llamada es obviamente inútil.
Ya que he escrito muchas veces sobre la rapidez de R, permítanme poner mis cinco centavos.
¡Querido Renat!
¡Tu ejemplo no es nada!
Has tomado dos funciones similares y has sacado una conclusión sobre el rendimiento de R en absoluto.
Las funciones que has dado no representan la potencia y diversidad de R en absoluto.
Deberías comparar operaciones de gran capacidad computacional.
Por ejemplo, multiplicación de matrices...
Midamos la expresión en R
c <- a*b
donde a y b son matrices de al menos 100*100 de tamaño. En tu código, asegúrate de que R utiliza MKL de Intel. Y esto se consigue simplemente instalando la versión correspondiente de R.
Si nos fijamos en R, hay montañas de código que contienen operaciones computacionalmente intensivas. Para ejecutarlas, se utilizan librerías, que son las más eficientes del momento.
Y la utilidad de R en el trading no está en las funciones que reescribiste (aunque también son necesarias), sino en los modelos. En una de las respuestas que te hice mencioné el paquete caret. Mira lo que es.... La implementación de cualquier modelo de trading prácticamente útil en el marco de este paquete y sobre µl te dará la respuesta
Además, no debes olvidar que cargar todos los núcleos de una comp es una rutina de R. Además puedes cargar comps vecinas en la red local.
PD.
Para mí la idea de comparar el rendimiento de MKL y R es cuestionable: estos dos sistemas tienen áreas temáticas completamente diferentes.
SanSanych, lo probaremos todo y publicaremos un benchmark. Pero primero vamos a completar la funcionalidad.
La prueba estaba justificada y reveló inmediatamente el problema. He presentado la justificación teórica y estoy seguro de que la sobrecarga del sistema de R se conservará para la abrumadora cantidad de funcionalidad.
Podemos multiplicar las matrices de tal manera que Intel perderá. No es ciencia de cohetes durante mucho tiempo, e Intel (o más bien, tales programadores de terceros dentro de la afiliación de la empresa) no es un campeón en el conocimiento mítico de sus procesadores.
Ya que he escrito muchas veces sobre la rapidez de R, déjame poner mis cinco centavos.
.................
Para San-Sanych y los demás.
San-Sanych, ya sabes lo mucho que te respeto ... ((S) Kataev y Feinzilberg, conocidos como "Ilf y Petrov"), a pesar de algunas de tus bromas post-soviéticas aquí.
Permítame aclararle algo importante:
1). El principal trabajo de un programador no es escribir programas, sino LEER programas, en particular los suyos propios. Cualquier programador del 95...99% de su tiempo se sienta y se queda mirando el monitor. ¿Escribe un programa? No, casi siempre lo lee. Por lo tanto, cuanto más cercano al lenguaje natural sea lo que lee en la pantalla, es decir, a lo que le enseñaron su madre, su padre, su abuela, su profesor de escuela, más eficazmente descifrará estas krakozebras lingüísticamente obedientes en la pantalla y encontrará la correspondencia entre el algoritmo y su programa.
2). Para los fines del punto (1) no hay nada mejor en promedio que el lenguaje C. Por eso, por ejemplo, yo personalmente (así como 2-3 personas responsables y no muy responsables) logré escribir un proyecto con 700+ subrutinas en C, MQL4, CUDA..... Y todo funciona.
3). Desde el punto de vista del punto (1), la variante orientada a objetos de C, es decir, C++, es mucho peor. (Pero de eso hablaremos en otra ocasión).
4). La compatibilidad total de C clásico y MQL4 es simplemente inestimable. Transferir un procedimiento de un lado a otro lleva medio minuto.
5). La principal ventaja de C+MQL4 es la CLARIDAD. Es decir, la comprensibilidad y transparencia de todo lo que está en la pantalla del programador.
Si comparamos C-MQL4 con su R, no debemos fijarnos en la velocidad y volumen del código escrito, sino en la CLARIDAD del texto. Es decir, su comprensibilidad. De lo contrario, el programador se quedará 24 horas mirando la pantalla en vanos intentos de entender qué hace el programa, qué parámetros tiene, por qué el autor los nombró así y, en general, por qué el programador lo hizo así y no de otra manera. Lo importante aquí no es la velocidad del programa, sino la corrección de su trabajo y la rapidez de su APLICABILIDAD para el programador final.
Desde este punto de vista, lo que ha hecho Metaquotes es desde luego un gran apoyo para aquellos que quieran insertar estadísticas en sus EAs. No hay nada comparable en cuanto a sencillez y comprensibilidad de las funciones. Y esto es importante. Especialmente si tienes cálculos delicados (y Forex y el trading en general requieren cálculos delicados).
Comparemos.
Así es como se ve la función de integración en C - MQL4:
Escribiré por partes, es más fácil escribir así.
Hay una función de integración trapezoidal dentro:
Todo es absolutamente claro y comprensible. Y lo que es importante, siempre funciona y funciona bien, es decir, con pocos errores incluso en MT4-MQL4, lo que ahorra mucho tiempo.
Pero si quieres averiguar por qué tienes errores incomprensibles cuando trabajas en R, o si simplemente quieres entender qué parámetros hay en el procedimiento de integración o qué método de integración han programado ahí, verás lo siguiente (que Dios me perdone por publicar esto para niños inmaduros programadores):
http://www.netlib.org/quadpack/
Esto es sólo el título de la función escrita originalmente en Fortran. El texto principal vendrá después. Este es el programa original utilizado en el paquete R para la integración.
¿Qué hay que entender aquí, dime?