Investigación en paquetes matriciales - página 5
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
Estupendo, es mi primer día de aprendizaje de R, responde a mis preguntas por favor, quiero comparar posibilidades de R y Matlab. Pero no seas hostil, sé equilibrado y tranquilo :).
1. Sí.
2. ¿Por qué? Necesitas un único MT4R.dll que es la puerta de entrada para transferir los datos a R y obtener los resultados de vuelta.
3. A todas las bases de datos existentes. No sólo eso, sino que tanto Microsoft como Oracle han integrado R en sus bases de datos.
4. R tiene varias opciones para interactuar con Matlab, desde el simple intercambio de archivos Matlab hasta la ejecución de funciones Matlab desde R. Si tienes experiencia en esta área, puedes implementar una excelente interfaz Matlab-MTterminal con R.
5. En R se realizan los paquetes para todas las direcciones de una ciencia y técnica y teniendo en cuenta los últimos logros. Puede empezar por aquí.
6. Hay más de uno. El más común es el ff.
En general, estoy sorprendido. Estás en medio de la nada. Mira los artículos 1 y 2 de este sitio y no entenderás mucho pero te harás una idea de cómo funciona el lenguaje.
Estoy terminando el segundo artículo sobre el aprendizaje profundo que espero enviaros mañana para su revisión y los ejemplos se adjuntarán... Si hay interés, creo que escribiré varios artículos sobre el nivel inicial (filtrado, descomposición, predicción, etc.). Y por supuesto, seguir indagando en el aprendizaje profundo, sobre todo porque Google abrió su biblioteca TensorFlow para todo el mundo. Y hay otros no menos interesantes y prometedores (mxnet, pyBrain).
Si un grupo de entusiastas se reúne, podemos organizar una rama de usuarios del lenguaje R.
Buena suerte
Por favor, describa el proceso de trabajo a través de este DLL con más detalle. ¿Y dónde conseguirlo?
¿Discutimos cómo podemos hacer una mejor integración con R?
Es un tema interesante y se puede desarrollar bien.
Hola.
Voy a añadir algo a lo que se ha dicho antes.
Se prefierela opción 1 por varias razones:
En esta variante simplemente proporcionamos la transferencia de datos al proceso R y recibimos datos de él. Lo que se proporciona en MT4R.mqh es más que suficiente por ahora.
Lo único que nos gustaría ver adicionalmente es la obtención de cotizaciones por solicitud del proceso R pasando por alto la terminal. No importa si desde los archivos/buffers locales del terminal o directamente desde el servidor de una empresa de corretaje. Pero no es un deseo crucial.
Mi opinión no profesional es quela variante 2 requiere cambios cardinales no sólo en el terminal, sino también en el editor. Y recuerdo el último rediseño cardinal de la terminal con un escalofrío. Esta variante puede desarrollarse simultáneamente con la realización de la primera variante y aplicarse cuando la mayoría de los clientes se acostumbren a ella, y sobre todo cuando vean las ventajas de utilizar este lenguaje. Por supuesto, la integración total del terminal y del editor con el lenguaje R es ideal.
Me alegro de que hayas prestado atención a esta dirección.
Buena suerte
¿Discutimos cómo podemos hacer una mejor integración con R?
Este es un tema interesante y podría desarrollarse bien.
Siempre me he preguntado por qué la MT no está incluida en R.
Si se observan los 15 años de MT, se trata de un desarrollo evolutivo, en el que la funcionalidad fue creciendo, pero lo principal -el cliente- siguió siendo lo mismo. Es un pseudotrader que utiliza el AT como herramienta.
1. La inclusión de la MT en R le permitirá unirse a la comunidad profesional de traders, aquellas organizaciones con no sólo cientos sino miles de traders que utilizan herramientas profesionales en forma de estadísticas, econometría, aprendizaje automático ....
2. No es baladí que la inclusión de la MT en R haga posible el uso de la MT en el proceso de enseñanza. En una época, enseñando sistemas mecánicos de trading como herramienta, elegí Quick y Metastock, aunque conocía el MT, pero tenía un lenguaje que había que enseñar a los alumnos, y no estaba previsto en el programa. La incorporación de la MT en R con el lenguaje algorítmico R como herramienta de escritura de EA, elimina todos los problemas de aprendizaje - R se aprende fuera de la conexión con los terminales.
Tal y como yo lo veo:
1. MT debe ser una GUI en R (hay ejemplos disponibles, así como una herramienta para construir tal GUI - shiny). Es muy deseable que esta GUI sea una copia de uno de los terminales, o mejor ambos
2. Lenguaje algorítmico R. Los Asesores Expertos están escritos en el lenguaje R, y todas las funciones específicas de negociación se implementan como un paquete. En este caso, según tengo entendido, la sintaxis para llamar a las funciones especiales seguirá siendo la misma. Esta es una solución estándar, ya que el rendimiento vendrá determinado por el lenguaje y la calidad de la escritura de estas funciones, y éstas, al estar escritas en C, y probadas durante muchos años, darán unos resultados de rendimiento comparables a los existentes. Quiero prestar atención a que la velocidad de ejecución de otros algoritmos computacionalmente intensivos en R sea máxima y no inferior a su implementación en otros lenguajes algorítmicos, ya que un programa en R suele llamar a paquetes, que para algoritmos computacionalmente intensivos no están implementados en R. A esto hay que añadir que la práctica habitual de realización de algoritmos computacionalmente intensivos prevé la carga de todos los núcleos del ordenador.
3. En mi opinión no profesional, los costes de mano de obra no serán grandes, dada la relación muy amistosa entre R y C y la cocina interna, que no podemos ver, puede ser transferida de la terminal existente a la nueva.
4. la parte del terminal en manos de los corredores no se modificará.
En cuanto los paquetes mencionados se incluyan en las réplicas de CRAN, las metacuotas obtendrán una publicidad estrecha en círculos amplios en lugar de una publicidad amplia en círculos estrechos. El terminal de Metakvot no tendrá competidores, ya que el único terminal de R disponible es IBrokers, que está vinculado a determinados corredores de bolsa de pago.
Siempre me he preguntado por qué la MT no está incluida en R.
Y siempre me he preguntado por qué empezaron a desarrollar ellos mismos un compilador de tipo C (me refiero a los primeros MQL4) en lugar de conseguir un compilador de C++ ya hecho y gratuito como GCC.
He trabajado para grandes empresas occidentales y a nadie se le ha ocurrido desarrollar desde cero su propio compilador de C++ para diversas aplicaciones integradas. Siempre tomaban gcc y hacían un port a un procesador específico.
Y, a juzgar por el hecho de que en 2006 se realizó con gran éxito un port a DSP de 4 procesadores con arquitectura NEON (hasta 6 instrucciones por reloj por núcleo), este compilador es bastante flexible para la adaptación. Es decir, el compilador realmente paralelizó las operaciones con un promedio de 2 a 4 operaciones por reloj por núcleo, sólo los cuellos de botella tuvieron que ser optimizados en asm.
Y ahora recordemos la porquería que era MQL4 hasta la versión 600.
Ahora en el tema. Como explicó Renat, la razón fue un deseo maníaco de hacer un compilador con el tonto y la protección de los intrusos. Aunque ni siquiera olía así antes de la versión 600, era un fallo sobre un fallo.
Pero, si se toman sus palabras al pie de la letra, ¿qué aspecto tiene R desde el punto de vista de la seguridad? Soy bastante nuevo en esto, llevo trabajando con Matlab desde el año 2000, así que por favor explicadme, si sabéis algo. ¿Puede encriptar los archivos de salida como los compiladores MQL4/5?
Además, por lo que entendí R sigue siendo un intérprete, significa que será aún más lento que el antiguo MQL4 y ciertamente más lento por órdenes de magnitud que el actual MQL5.
Siempre me he preguntado por qué empezaron a desarrollar un compilador tipo C (me refiero a los primeros MQL4) en lugar de utilizar un compilador libre de C++ como GCC.
He trabajado para grandes empresas occidentales y a nadie se le ha ocurrido desarrollar desde cero su propio compilador de C++ para diversas aplicaciones integradas. Siempre tomaban gcc y hacían un port a un procesador específico.
Y, a juzgar por el hecho de que en 2006 se realizó con gran éxito un port a DSP de 4 procesadores con arquitectura NEON (hasta 6 instrucciones por reloj por núcleo), este compilador es bastante flexible para la adaptación. Es decir, el compilador realmente paralelizó las operaciones con un promedio de 2 a 4 operaciones por reloj por núcleo, sólo los cuellos de botella tuvieron que ser optimizados en asm.
Y ahora recordemos la porquería que era MQL4 hasta la versión 600.
Ahora en el tema. Como explicó Renat, la razón fue un deseo maníaco de hacer un compilador con el tonto y la protección de los intrusos. Aunque ni siquiera olía así antes de la versión 600, era un fallo sobre un fallo.
Pero, si se toman sus palabras al pie de la letra, ¿qué aspecto tiene R desde el punto de vista de la seguridad? Soy bastante nuevo en esto, llevo trabajando con Matlab desde el año 2000, así que por favor explicadme, si sabéis algo. ¿Puede encriptar los archivos de salida como los compiladores MQL4/5?
Además, por lo que entiendo R sigue siendo un intérprete, significa que será aún más lento que el viejo MQL4 y ciertamente más lento por órdenes de magnitud que el actual MQL5.
Lee mis posts sobre la velocidad. Brevemente. R es en gran medida un shell y los problemas que planteas no tienen nada que ver con R en absoluto - todos estos problemas se resuelven dentro de funciones implementadas en otros lenguajes. Si hablamos de encriptación, ciertamente no tiene nada que ver con la implementación prevista del terminal - se puede tomar cualquier cosa existente.
Tengo la costumbre de leer los posts anteriores, así que los consejos no son para mí ))
**************************
Tengo que intentar traducir algunos de mis programas de Matlab a R para comparar la velocidad. Si consigo solucionarlo para el fin de semana, lo haré y os lo haré saber. Matlab es bastante lento, hago muchas cosas en C# o C++ y lo conecto como DLL para ganar velocidad.
La propia R es tres veces retardada. Es un intérprete. No hay problemas con la depuración en absoluto, al principio empecé a usar un depurador, y luego resultó ser inútil.
Hablando de la velocidad R, hay varias consideraciones aquí.
1. se puede traducir a código de bytes, pero es una cataplasma
**************************
¿Sabes que MQL4/5 son lenguajes compilables? ¿Y para tu sueño de un terminal R similar al de MT, Metakvotam tendrá que hacer un compilador de R?
Pero, si se toman sus palabras al pie de la letra, ¿qué aspecto tiene la R desde el punto de vista de la seguridad? Soy bastante nuevo en esto, llevo trabajando con Matlab desde el año 2000, así que por favor explicadme, si sabéis algo. ¿Puede encriptar los archivos de salida como los compiladores MQL4/5?
Además, según tengo entendido, R sigue siendo un intérprete, lo que significa que será aún más lento que el viejo MQL4 y ciertamente más lento en órdenes de magnitud que el actual MQL5.
1. todo está encriptado de diferentes maneras fiables.
2) Esto es fundamentalmente erróneo. Todos los cálculos pesados se escriben en C y en paralelo.
Prueba y aprende.
Buena suerte
Seamos realistas.
Hoy el terminal MT4 con el EDITOR funciona sin problemas (al menos para mí). Sólo tenemos que añadir la cosa más pequeña para interactuar con R.
Los desarrolladores tienen una mejor idea de cómo hacerlo. Lo principal es hacerlo rápidamente y sin quebraderos de cabeza para los usuarios.
Buena suerte