Yo uso ambos. A menudo prototipo de funciones y algoritmos en Matlab porque, como se dijo, es más fácil expresar un algoritmo en algo cercano a un lenguaje matemático puro.
R tiene excelentes bibliotecas. Todavía lo estoy aprendiendo, pero estoy empezando a dejar a Matlab en el polvo porque una vez que conoces R, también es bastante fácil crear prototipos de funciones allí.
Sin embargo, creo que si desea que los algoritmos funcionen eficientemente dentro de un entorno de producción, es mejor pasar a un lenguaje compilado como C ++. Tengo experiencia en envolver C ++ en Matlab y R (y sobresalir para el caso), pero he tenido una mejor experiencia con R. Descargo de responsabilidad: Siendo un estudiante graduado, no he usado una versión reciente de Matlab para mis dlls, He estado trabajando casi exclusivamente en Matlab 7.1 (que tiene como 4 años). Quizás las versiones más nuevas funcionen mejor, pero puedo pensar en dos situaciones fuera de mi cabeza donde un dll C ++ en la parte posterior de Matlab causó que Windows XP apareciera en la pantalla azul porque caminé inapropiadamente fuera de los límites de una matriz, un problema muy difícil de resolver. depurar si su computadora se reinicia cada vez que comete ese error ...
Por último, la comunidad R parece estar creciendo mucho más rápido y con mucho más impulso que la comunidad de Matlab. Además, como es gratis, tampoco tiene que lidiar con el administrador de licencias flexlm de Godforsaken.
Nota: Casi todo mi desarrollo está en algoritmos MCMC en este momento. Realizo alrededor del 90% en producción en C ++ con la visualización en R usando ggplot2.
Actualización para comentarios paralelos:
Una buena parte de mi tiempo de desarrollo en este momento lo paso en paralelo a las rutinas MCMC (es mi tesis doctoral). He usado la caja de herramientas paralelas de Matlab y la solución de Star P (¿supongo que ahora es propiedad de Microsoft? Dios, otra está engullida ...) Encontré que la caja de herramientas paralelas es una pesadilla de configuración , cuando la usé, requirió acceso raíz a cada nodo de cliente. Creo que han solucionado ese pequeño "error" ahora, pero sigue siendo un desastre. Encontré que la solución * 'p es elegante, pero a menudo difícil de perfilar. No he usado Jacket , pero he escuchado cosas buenas. Tampoco he usado las versiones más recientes de la caja de herramientas paralelas que también admiten el cálculo de GPU.
Prácticamente no tengo experiencia con los paquetes paralelos R.
Según mi experiencia, el código de paralelización debe ocurrir en el nivel de C ++ donde tiene una granularidad de control más fina para la descomposición de tareas y la asignación de memoria / recursos. Me parece que si intentas paralelizar programas en un nivel alto, a menudo solo recibes una aceleración mínima a menos que tu código sea trivialmente descomponible (también llamado paralelismo ficticio). Dicho esto, incluso puedes obtener aceleraciones razonables usando una sola línea en el nivel de C ++ usando OpenMP:
#pragma omp parallel for
Los esquemas más complicados tienen una curva de aprendizaje, pero realmente me gusta hacia dónde van las cosas de gpgpu. A partir de JSM este año, las pocas personas con las que hablé sobre el desarrollo de GPU en R lo citan como solo "dedos en el fondo", por así decirlo. Pero como se dijo, tengo una experiencia mínima: cambiar en el futuro cercano.