# Is Matlab/octave or R better suited for monte carlo simulation?

I started to do Monte Carlo in R as a hobby, but eventually a financial analyst advised to migrate to Matlab. I'm an experienced software developer. but a Monte Carlo beginner. I want to construct static models with sensitivity analysis, later dynamic models. Need good libraries/ algorithms that guide me.

To me seems that R has excellent libraries, and I suspect mathlab is preferred by inexperienced programmers because of the easy pascal-like language. The R language is based on scheme and this is hard for beginners, but not for me. If Matlab/ Octave has not advantages on the numerical/ library side I would stick with R.

• R is based on Scheme but is pretty good in pretending to the beginners that it is rather C based. – mbq Oct 12 '10 at 14:31
• > I will not post this as an answer because there are many people more knowledgeable in these things than me. However, i think that concerning speed you have to distinguish between R base and the mix good programmer/great packages. A good programmer can leverage some the tools in cran such as multicore, GPUtools&magma (soon but not yet usefull for MCMC), Rcpp,... to make a pretty fast code. I don't think matlab central has anything comparable to offer. – user603 Oct 12 '10 at 14:56
• @kwak -- I probably should've posted my answer as a comment too. Sorry about that. – M. Tibbits Oct 12 '10 at 15:02
• MT, that's crazy - your answer is great. If anything, kwak should make his a proper answer, too. Let those more knowledgeable vote or answer as they see fit. – Matt Parker Oct 12 '10 at 15:33
• Apologies in advance for the necropost. The GNU Octave financial package octave.sourceforge.net/financial now supports (as of 0.5.0) Monte Carlo simulation. It is significantly faster than the MATLAB version as the code is written without for loops. For benchmarking (compared with MATLAB) and a tutorial, see parsiad.ca/post/simulate-sdes-in-gnu-octave-financial-package. I should also publicize my bias, as I am the author of these methods. – parsiad Jun 30 '16 at 17:31

I use both. I often prototype functions & algorithms in Matlab because, as stated, it is easier to express an algorithm in something which is close to a pure mathematical language.

R does have excellent libraries. I'm still learning it, but I'm starting to leave Matlab in the dust because once you know R, it's also fairly easy to prototype functions there.

However, I find that if you want algorithms to function efficiently within a production environment, it is best to move to a compiled language like C++. I have experience wrapping C++ into both Matlab and R (and excel for that matter), but I've had a better experience with R. Disclaimer: Being a grad student, I haven't used a recent version of Matlab for my dlls, I've been working almost exclusively in Matlab 7.1 (which is like 4 years old). Perhaps the newer versions work better, but I can think of two situations off the top of my head where a C++ dll in the back of Matlab caused Windows XP to blue screen because I walked inappropriately outside an array bounds -- a very hard problem to debug if your computer reboots every time you make that mistake...

Lastly, the R community appears to be growing much faster and with much more momentum than the Matlab community ever had. Further, as it's free you also don't have deal with the Godforsaken flexlm license manager.

Note: Almost all of my development is in MCMC algorithms right now. I do about 90% in production in C++ with the visualization in R using ggplot2.

Update for Parallel Comments:

A fair amount of my development time right now is spent on parallelizing MCMC routines (it's my PhD thesis). I have used Matlab's parallel toolbox and Star P's solution (which I guess is now owned by Microsoft?? -- jeez another one is gobbled up...) I found the parallel toolbox to be a configuration nightmare -- when I used it, it required root access to every single client node. I think they've fixed that little "bug" now, but still a mess. I found *'p solution to be elegant, but often difficult to profile. I have not used Jacket, but I've heard good things. I also have not used the more recent versions of the parallel toolbox which also support GPU computation.

I have virtually no experience with the R parallel packages.

It's been my experience that parallelizing code must occur at the C++ level where you have a finer granularity of control for task decomposition and memory/resource allocation. I find that if you attempt to parallelize programs at a high level, you often only receive a minimal speedup unless your code is trivially decomposable (also called dummy-parallelism). That said, you can even get reasonable speedups using a single-line at the C++ level using OpenMP:

#pragma omp parallel for


More complicated schemes have a learning curve, but I really like where gpgpu things are going. As of JSM this year, the few people I talked to about GPU development in R quote it as being only "toes in the deep end" so to speak. But as stated, I have minimal experience -- to change in the near future.

• +1 for C++; while it is quite easy to embed C/C++ to R I often wrap my codes and run them inside R -- then it is nicer to pass parameters, do live visualisation and obviously analyse results without thinking of output file format. – mbq Oct 12 '10 at 16:42
• well put; MC will eventually require one to move to C/C++. I do not have enough experience in R to comment, but have had a number of headaches using C/C++ with Matlab due to different versions of shared object libraries (under Linux) being pulled in by the Matlab executable than what I want to link with my code. – shabbychef Oct 12 '10 at 16:54
• tibbits: How do you generate RN's when using openMP? – csgillespie Oct 13 '10 at 9:05
• Right now, I'm not. The most expensive parts of my MCMC algorithms are computing several likelihoods so I try to bunch them together best as possible and compute them in parallel. But all of the setup, RN generation (for proposals), are done on a single cpu core. For parallel RNGs, I'd start with DC for the Mersenne Twister -- but I've never personally used it beyond a trivial translation to CUDA for GPUs (more as an exercise really). – M. Tibbits Oct 13 '10 at 11:35

To be honest, I think any question you ask around here about R vs ... will be bias towards R. Remember that R is by far the most used tag!

What I do

My current working practice is to use R to prototype and use C when I need an extra boost of speed. It used to be that I would have to switch to C very quickly (again for my particular applications), but the R multicore libraries have helped delay that switch. Essentially, you make a for loop run in parallel with a trivial change.

I should mention that my applications are very computationally intensive.

Recommendation

To be perfectly honest, it really depends on exactly what you want to do. So I'm basing my answer on this statement in your question.

I want to construct static models with sensitivity analysis, later dynamic models. Need good libraries/ algorithms that guide me

I'd imagine that this problem would be ideally suited to prototyping in R and using C when needed (or some other compiled language).

On saying that, typically Monte-Carlo/sensitivity analysis doesn't involve particularly advanced statistical routines - of course it may needed other advanced functionality. So I think (without more information) that you could carry out your analysis in any language, but being completely biased, I would recommend R!

• I like the part about "My current working practice is to use R to prototype and use C when I need an extra boost of speed." - it sounds like the job description of my poor unworthy self and the C++ developers in the next office... and I think it really captures basically any situation involving R, C/C++ and an issue in statistical computation. – Stephan Kolassa Oct 12 '10 at 20:48

Although I almost exclusively use R, I really admire the profiler in Matlab.
When your program is kind of slow you normally want to know where the bottleneck is. Matlab's profiler is a great tool for achieving this as it tells you how much time is spend on each line of the code.

At least to me, using Rprof is incomparably worse. I can't figure out which call is the bottleneck. Using Rprof you don't get the information on how much time is spend on each line, but how much time is spend on each primitive function (or so). However, a lot of the same primitive functions are called by a lot of different functions.

Although I recommend R (because it is just great: free, extremely powerful, ...) if you know you have to profile your code a lot, Matlab is way better. And to be fair, there are multicore and parallel computing toolboxes in Matlab (though, extremely pricey).

• I completely agree @Henrik. If you're concerned about profiling, Matlab has an excellent profiling tool (even back in version 7.1!!). Rprof on the otherhand leaves a lot to be desired. I end up profiling by executing each command several times in a for loop and comparing the system.time difference amongst different versions. Here is an interesting case study – M. Tibbits Oct 12 '10 at 16:57

If your simulations will involve relatively sophisticated techniques, then R is the way to go, because it is likely that routines you'll need will be available in R, but not necessarily in matlab.

In my opinion, Matlab is an ugly language. Perhaps it's gotten default arguments and named arguments in its core by now, but many examples you find online do the old "If there are 6 arguments, this, else if there are 5 arguments this and that..." and named arguments are just vectors with alternating strings (names) and values. That's so 1970's that I simply can't use it.

R may have its issues, and it is also old, but it was built on a foundation (Scheme/Lisp) that was forward-looking and has held up rather well in comparison.

That said, Matlab is much faster if you like to code with loops, etc. And it has much better debugging facilities. And more interactive graphics. On the other hand, what passes for documenting your code/libraries is rather laughable compared to R and you pay a pretty penny to use Matlab.

All IMO.