Cambio de C++ a R - limitaciones/aplicaciones

Question

Hace poco que he empezado a explorar y aprender R (especialmente porque Dirk recomendado RStudio y mucha gente aquí habla bien de R ). Yo soy más bien C(++) orientado, por lo que me hizo pensar - cuáles son las limitaciones de R ¿en particular en términos de rendimiento?

Estoy tratando de sopesar la C++/Python/R alternativas para la investigación y estoy considerando si conocer R lo suficientemente bien vale la pena la inversión de tiempo.

Los paquetes disponibles parecen bastante prometedores, pero hay algunas cuestiones en mi mente que me mantienen a raya por el momento:

• ¿Cómo de eficiente es R cuando se trata de importar grandes conjuntos de datos? Y en primer lugar, ¿qué es gran en términos de R ¿desarrollo? Solía procesar un par de cientos de archivos CSV en C++ (alrededor de 0,5M de valores supongo) y recuerdo que era meramente aceptable. ¿Qué puedo esperar de R ¿aquí? A juzgar por Los espectaculares resultados de Jeff Supongo que con una solución adecuada a largo plazo (no CSV) debería ser capaz incluso de cambiar al procesamiento de ticks sin obstáculos. ¿Pero qué pasa con la manipulación de datos ad-hoc? ¿Es tan visible la diferencia de rendimiento (en comparación con implementaciones de más bajo nivel)? ¿O es sólo una leyenda urbana?
• ¿Cuáles son las opciones de desarrollo de la interfaz gráfica de usuario? Digamos que me gustaría ir más allá del análisis orientado a la investigación, como el desarrollo de interfaces de usuario completas para el análisis de inversiones / comercio, etc. De lo que he encontrado mencionado aquí y en StackOverflow con las fijaciones apropiadas soy libre de usar Python y aún más la cadena en Qt si surge tal necesidad. Pero el despliegue de una bestia así debe ser una verdadera molestia. ¿Cómo se puede hacer frente a ella?

En general veo R me permite mezclarlo y combinarlo con una plétora de otros lenguajes (de cualquier manera - usando adiciones de bajo nivel en R o incrustar/invocar R en proyectos escritos en otro idioma). Eso parece bonito, pero ¿tiene sentido (me refiero a pensar en ello desde la fase de inicio/concepto, no a ampliar soluciones preexistentes)? ¿O es mejor quedarse con un solo lenguaje (inserte lo que le guste/tenga experiencia)?

Así que para resumir: ¿En qué aplicaciones de finanzas cuantitativas está R una (muy) mala elección (o al menos puede serlo)?

Answer 1

No tienes que cambiar no es o / o después de todo.

Utiliza cualquiera de los dos donde tenga ventaja: R para las exploraciones, el modelado, ... y C++ para las implementaciones de fuerza industrial y alto rendimiento (con un posible coste en términos de tiempo de codificación).

Y (con la obvia Rcpp plug coming) puedes incluso combinar ambos.

Answer 2

R puede ser bastante lento, y es muy exigente con la memoria. Mi conjunto de datos es de sólo 8 GB más o menos, y tengo una máquina con 96 GB de RAM, y siempre estoy luchando con la gestión de la memoria de R. Muchas de las funciones de estimación del modelo capturan un enlace a su entorno, lo que significa que puedes estar manteniendo un puntero a cada subconjunto de los datos con los que estás tratando. SAS era mucho mejor para tratar con conjuntos de datos grandes, pero R es mucho más agradable de tratar. (Esto es en el contexto de la modelización del prepago y el impago de las hipotecas).

La importación de los conjuntos de datos es bastante fácil y rápida, según mi experiencia. El problema es el aumento de los requisitos de memoria para procesar los datos.

Cualquier cosa que no sea fácilmente vectorizable parece que sería un problema. P&L backtesting para una estrategia que depende del estado actual de la cartera parece difícil. Si usted está buscando en el P&L residual de la cobertura de una cartera de renta fija, con las métricas de riesgo completo, que va a ser difícil.

Dudo que mucha gente quiera escribir un modelo de estructura de términos en R o un motor monte-carlo.

Sin embargo, a pesar de todo esto, R es una herramienta muy útil para tener en su caja de herramientas. Pero no es exactamente una potencia de cálculo.

No sé nada sobre las opciones de la GUI.

Answer 3

No soy un defensor de R, pero puedo atestiguar que R es trivialmente muy, muy bueno en el análisis de datos. Es esencialmente un lenguaje funcional tipo LISP lo suficientemente domesticado como para hacerte productivo en una tarde. Es imbatible a la hora de obtener datos en su sistema, analizarlos y producir una salida de alta calidad, ya sean informes o gráficos en látex. He utilizado varios lenguajes (desde SAS hasta Python), y ninguno se acerca a la productividad de R cuando se trata de análisis de datos avanzados. Tiene un conjunto de paquetes sin parangón, con gran redundancia: hay 4 paquetes sobre el filtro de Kalman, y casi 10 paquetes sobre diversas regresiones regularizadas por sí solas. Muy a menudo, los paquetes complementan artículos que se acaban de publicar, con lo que se tiene acceso a la tecnología más reciente. No es un problema consumir conjuntos de datos de 100M de filas o más, dada la suficiente memoria. Los que se quejan de la gestión de la memoria en R deberían probar MATLAB. Claro, es lento, pero considera esto:

• El álgebra lineal es tan rápida como C++, y la interfaz con LAPACK es mucho más fácil en R que en mucho más fácil en R que en C++;
• existen APIs para BDs específicas, almacenes de valores clave y ODBC);
• muchos paquetes están optimizados para la velocidad y escritos en C o Fortran;
• Para el 99% de las aplicaciones es suficientemente rápido;
• Para el 1% restante de uso en el que no hay cuello de botella por computación o gestión de datos, puedes acelerar las cosas en C, C++, Fortran, Java.

Yo mantendría que R bien codificado puede ser más rápido y más robusto que un código C++ pobre. R puede utilizarse en producción, aunque con cierto cuidado, y no como lenguaje principal. Definitivamente no es adecuado para hacer GUIs.

Me pareció que el enchufe para Python era un poco fuera de tema, pero diré que Python es sin duda uno de los lenguajes más versátiles y fáciles (lo digo como un cumplido), y Cython es una gran ventaja. Aun así, creo que los lenguajes, al igual que las personas, deben ser juzgados en base a lo que son mejores, no a lo que son lo suficientemente bueno en. Yo afirmaría que R es mejor para el análisis de datos, y que su sintaxis es ligeramente mejor que la de Python para este propósito. Pasará un tiempo hasta que Python cuente con los paquetes de dominio específico y los paquetes de visualización de R, y lo que es más importante, con la gente que hay detrás de ellos. Pero estoy de acuerdo en un punto muy importante: la mayoría de los fondos de cobertura quant realizan análisis de datos relativamente elementales, y Python+Numpy+Pandas es una elección sensata como lenguaje único.

Answer 4

Como descargo de responsabilidad, soy un destacado defensor del uso de Python para construir sistemas de producción para las finanzas cuánticas (charla antigua pero: http://python.mirocommunity.org/video/1531/pycon-2010-python ...). He tenido mucho éxito al hacerlo y, en gran medida, como resultado de mi ejemplo, muchos otros talleres de cuantificación han elegido la ruta de Python con excelentes resultados. La biblioteca pandas Python (http://pandas.sourceforge.net) es un resultado de código abierto de mi trabajo de propiedad.

Veo que otro fan de mi trabajo ya ha publicado aquí =)

Mi pregunta es: ¿por qué programar en C++? No creo que nadie discuta que es un lenguaje increíblemente poco productivo en relación con Python o R. Pero Python y R son lentos para el código iterativo y procedimental. La casi panacea para los Pythonistas es usar Cython (http://cython.org) para desarrollar código de velocidad C, pero que toma tal vez sólo 1.5-2x más tiempo que escribir código Python (para obtener todas las declaraciones de tipo correctas, etc.). También puedes llamar directamente a los métodos de las bibliotecas C / C++ usando Cython, así que realmente es lo mejor de ambos mundos en mi experiencia.

Creo que, en general, es mejor evitar los sistemas híbridos si es posible, ya que la depuración a través del "puente" es un problema espinoso. Normalmente se acaba con más código del que se había planeado en el lenguaje de mayor productividad (por ejemplo, R). Me gusta Python porque Python es bueno en todas las cosas en las que R no es bueno. Sí, las bibliotecas de estadística de Python son muy débiles (aunque estamos progresando en http://statsmodels.sourceforge.net ) en comparación con CRAN, pero en las finanzas cuantitativas resulta que el 90% del modelado y el análisis de datos que se hace en realidad no es tan sofisticado estadísticamente. Es en gran medida un problema de manipulación de datos relacionales y de procesamiento de series temporales (de lo que pandas se encarga en gran medida - tiene características de alineación de datos mucho mejor integradas que casi cualquier cosa en R, también).

Python también es excelente para construir interfaces gráficas de usuario. He utilizado wxPython y PyQt y he comprobado que en una tarde puedo crear una interfaz gráfica de usuario que me habría llevado una semana o más en Java o C++.

Answer 5

La mayor debilidad y la mayor fortaleza de R es que no es un lenguaje fuertemente tipado. Por lo tanto, las tareas fáciles en los lenguajes fuertemente tipados, como la refactorización, las comprobaciones del autocompilador, las pruebas unitarias, etc., pueden ser más difíciles en R.

Por otro lado, se puede crear rápidamente un prototipo en el lenguaje R. R es un lenguaje interpretado: convierte dinámicamente los tipos. R es también una excelente herramienta de visualización y análisis (biblioteca GGplot2). También hay una maravillosa comunidad de desarrolladores de R que están creando nuevas soluciones para los problemas todo el tiempo.

El R Inferno es una lectura esencial antes de desarrollar código de producción con R.