Ich benutze beides. Ich habe in Matlab oft Funktionen und Algorithmen prototypisiert, weil es, wie gesagt, einfacher ist, einen Algorithmus in etwas auszudrücken, das einer rein mathematischen Sprache nahekommt.
R hat ausgezeichnete Bibliotheken. Ich lerne es immer noch, aber ich lasse Matlab langsam im Staub, denn sobald Sie R kennen, ist es auch ziemlich einfach, dort Funktionen zu prototypisieren.
Wenn Sie jedoch möchten, dass Algorithmen in einer Produktionsumgebung effizient funktionieren, empfiehlt es sich, zu einer kompilierten Sprache wie C ++ zu wechseln. Ich habe Erfahrung darin, C ++ sowohl in Matlab als auch in R zu packen (und diesbezüglich zu übertreffen), aber ich habe eine bessere Erfahrung mit R. Haftungsausschluss: Als Student habe ich keine aktuelle Version von Matlab für meine DLLs verwendet. Ich habe fast ausschließlich in Matlab 7.1 gearbeitet (das ist ungefähr 4 Jahre alt). Vielleicht funktionieren die neueren Versionen besser, aber ich kann mir zwei Situationen vorstellen, in denen eine C ++ - DLL auf der Rückseite von Matlab dazu führte, dass Windows XP einen Bluescreen bekam, weil ich mich unangemessen außerhalb der Grenzen eines Arrays befand - ein sehr schweres Problem Fehlerbehebung, wenn Ihr Computer jedes Mal neu startet, wenn Sie diesen Fehler machen ...
Schließlich scheint die R-Community viel schneller und dynamischer zu wachsen, als es die Matlab-Community jemals getan hat. Da es kostenlos ist, müssen Sie sich auch nicht mit dem Godforsaken Flexlm License Manager auseinandersetzen.
Hinweis: Fast meine gesamte Entwicklung befasst sich derzeit mit MCMC-Algorithmen. Ich mache ungefähr 90% in der Produktion in C ++ mit der Visualisierung in R mit ggplot2.
Update für parallele Kommentare:
Ein beträchtlicher Teil meiner Entwicklungszeit wird derzeit für die Parallelisierung von MCMC-Routinen aufgewendet (dies ist meine Doktorarbeit). Ich habe Matlab parallel Toolbox und Star P-Lösung verwendet (was ich jetzt im Besitz von erraten Microsoft ?? - jeez ist ein anderer verschlungen ...) Ich habe die parallel Toolbox fand eine Konfiguration seinen Alptraum - wenn ich es benutze, Es erforderte Root-Zugriff auf jeden einzelnen Clientknoten. Ich denke, sie haben diesen kleinen "Bug" jetzt behoben, aber immer noch ein Chaos. Ich fand die Lösung elegant, aber oft schwer zu profilieren. Ich habe Jacket nicht benutzt , aber ich habe gute Dinge gehört. Ich habe auch nicht die neueren Versionen der parallelen Toolbox verwendet, die auch die GPU-Berechnung unterstützen.
Ich habe praktisch keine Erfahrung mit den R-Parallel-Paketen.
Ich habe die Erfahrung gemacht, dass die Parallelisierung von Code auf C ++ - Ebene erfolgen muss, wo Sie eine genauere Kontrolle über die Aufteilung der Aufgaben und die Speicher- / Ressourcenzuweisung haben. Ich finde, wenn Sie versuchen, Programme auf hoher Ebene zu parallelisieren, erhalten Sie oft nur eine minimale Beschleunigung, es sei denn, Ihr Code ist trivial zerlegbar (auch als Dummy-Parallelität bezeichnet). Das heißt, Sie können mit OpenMP sogar eine vernünftige Beschleunigung erzielen, wenn Sie eine einzelne Zeile auf C ++ - Ebene verwenden:
#pragma omp parallel for
Kompliziertere Schemata haben eine Lernkurve, aber ich mag es wirklich, wohin die Dinge mit GPGPU gehen. Seit JSM in diesem Jahr wird es von den wenigen Personen, mit denen ich über die GPU-Entwicklung in R gesprochen habe, sozusagen als "Zehen im tiefen Bereich" bezeichnet. Aber wie gesagt, ich habe nur minimale Erfahrung - in naher Zukunft zu ändern.