The pro and cons of using Mathematica for simulations

Why use Mathematica for simulations?

1. Programming is fast. Especially for smaller simulations, I find that I can solve a given problem using Mathematica in one half to one tenth of the time it would take me to solve it using Pascal, my previous language of choice. There are a number of reasons for this, many of which will become apparent in the course of this tutorial.

2. Output is pretty.  As you will already know if you've played around with the graphics routines provided in Mathematica, it is easy to generate all sorts of fancy customized representations of your data, from contour plots to pie charts to three-dimensional surfaces. Unfortunately, getting these fancy representations up to publication quality is not so easy - but I cover those issues in a separate tutorial.

3. Code is elegant. Once you get the hang of using Mathematica as it was designed to be used, instead of as a poor substitute for a procedural language like C or Pascal, I suspect you find that your code is extremely elegant. For many kinds of problems, a simulation written properly in Mathematica will be less than a tenth as long as the equivalent written in Pascal, and far easier to understand at a glance.

4. Programs are easy to debug. This one you'll just have to see you for yourself. I personally find that in Mathematica programs it is maybe a tiny bit harder to fix syntax errors, but it is far easier to find logical errors.  Using Mathematica, it is easier to independently test each component of the program to make sure it is functioning as you intend. And this worth a lot - I have never worried that I might be about to publish results based on a simulation with syntax errors, after all. I wish I could say the same of logical errors.

5. Programs mirror the processes that they simulate. I find that Mathematica simulations more closely mirror the actual mathematical structure of the processes that they are designed to simulate. This makes it easier to catch logical errors (as mentioned above), and also can really help you understand the nature of the system with which you are working.

6. Data is easily displayed in multiple forms. When programming in C or Pascal, I sometimes want to see my data summarized in a different format, but often it's pain to actually do so, and I decide not to bother. This can be a real loss, because sometimes by switching perspective on the data one can see entirely new aspects of the system being studied. In Mathematica, I find it very easy to look at the data in multiple ways. This holds for a number of reasons; among them is the ease with which Mathematica manipulates lists and multidimensional arrays and extracts data from them, the ease with which various graphical summaries can be produced, and the general trend in Mathematica programming of storing al the data generated in the simulation and only after the fact summarizing the results via various measures (this approach is treated in detail below).

Why avoid Mathematica for simulations?

1. Computational speed is slow. I have not done the benchmarks myself, but Mathematica is clearly not as quick as C for doing many computationally-intensive tasks. If you have a really big simulation that is going to take days to weeks to run, people claim that you can get up to hundred-fold increases in speed by programming in tight efficient C.

2. Syntax can be difficult. There is definately a learning curve where syntax is concerned. Mathematica syntax can seem rigid (though almost always for very good reason, once you understand why things work as they do). Moreover the error messages can be extremely confusing. Often a program or a line of code will not work, and the associated error message will give you almost no clue what could be going wrong. You get over this, in time. One learns how to interpret the error messages that once seemed cryptic, and quickly find any problems. Moreover, any difficulties in finding and fixing syntax errors are more than compensated for by the improvements in finding and fixing logical errors, in my experience.

3. User interface programming seems tricky. Writing programs with bulletproof user interfaces - particularly for end-users with no Mathematica background - seems difficult. I honestly don't have enough experience with this to be certain one way or the other. Perhaps further experience, or experience with Mathematica 4.0  will change my mind here.

4. Mathematica is proprietary software. Even worse than that, it is protected by an absurdly complicated, rarely functional, and hopelessly frustrating on-line registration and password scheme that - in my personal experience - usually imposes at least a day's wait between installing and actually using the program. I would imagine that the hassles involved would drive away ten paying customers for every pirate that they deter. It's a very useful piece of proprietary software, and no comparable GPL alternative is available, but it is still proprietary, and the licensing system seems to me to exemplify the very worst characteristics of proprietary software.


Converted by Mathematica      November 5, 1999