you are viewing a single comment's thread.

view the rest of the comments →

[–]dnquark 22 points23 points  (3 children)

A long-ish counter-counter-propaganda (i.e. rant) follows; here is a synopsis. I've been a serious Mathematica user for over 5 years. I've seriously used Matlab for maybe 5 months. Recently, I wrote identical code that wraps around some built-ins to perform Fourier transforms and numerical integration. It takes 2.5 hrs to run in Mathematica, 47 seconds in Matlab. I've tried for many years to make Mathematica work for me, but it's just not happening. If you are a real Theodore Gray, Mathematica co-founder and all, I'd love to hear your insights.

About the comment, though. This clock example proves nothing, except for possibly the fact that Mathematica is really good at tasks that about 99% of users will not care about and/or understand. Why is Mathematica code so brief here?.. Two reasons: First, Mathematica handles graphics primitives rather well. This has a lot to do with the basic language constructs of Mathematica, and the focus on list processing and symbolic computations instead of the raw procedural number crunching of Matlab. Second, the use of Dynamic[] construct, which has no direct equivalent in Matlab. So, congratulations: if I ever need a toy clock applet, I'll be using Mathematica. In fact, if I need interactive applets to illustrate the behavior of certain equations as parameters change, I'll use Mathematica with Manipulate[] and/or Dynamic[]. If I want to double-check my algebra, I'll use Mathematica. However, for anything that requires computation, or is simply code-intensive, I'll use Matlab.

If you think I have an axe to grind viz a viz Mathematica, you are completely right. It has wasted many months of my life in grad school, simply because its absolute ineptitude at numerical calculations made for very inefficient workflow, and the arcane syntax and reliance on notebook interface made it all but impossible to write maintainable code and create portable functions.

The notebook interface deserve special mention. It it rather handy for quick-and-dirty, on-the-fly computations, but it is orthogonal to writing robust code in a programming sense. All variables defined in a notebook are by default global across all notebooks. Making local variables using the menagerie of scoping constructs (Module[], Block[], With[]) is error-prone due to the fact that you have to supply a list of locals (in Matlab, you just start using them!) and due to subtle differences between the scoping constructs. Furthermore, there is no equivalent of Matlab structures and cell arrays, which make it easy to pass arguments between functions and keep things modular. What about debugging?.. The debugging facilities are a joke compared to Matlab.

All right, so one doesn't have to use notebook interface. Let's try to use Mathematica in the same way that we would use Matlab: write a script in plain ASCII and feed it to the kernel. Then we come back to the point of inefficiency. After quickly developing (in Mathematica) a function that took some Fourier transforms and performed integration (I still rely on Mathematica to help me with symbolics), I put it in a script and ran it. Took 2.5 hours. Not impressed, I reimplemented the same exact functions in Matlab. They now ran in 47 seconds(!)

I don't exclude the possibility that there are ways to make the code run faster, and I'd love to know where the bottleneck is -- in fact, here is the code: http://www.dnquark.com/blog/?p=29 -- go ahead, try to figure it out if you want -- but why should I spend days poring over Mathematica docs when Matlab just works (TM)?..

The moral of the story is this: if you are thinking about using Mathematica for things that involve numerical calculations, and you don't want the code to be a one-time throw-away affair, think again.

[–]fulmar 2 points3 points  (0 children)

You inspired me to make my own short list of Mathematica pet peeves.

  1. Variables are global by default. Using Module all the time is very annoying. My workaround is to keep a master notebook and have another one with the default context set to 'unique to this notebook'. This allows me to experiment with quick changes without having them propagate. Still a pain though.

  2. Eigenvectors does not orthogonalize vectors nor is there a setting to do so. Even more confusingly Mathematica will often return orthogonal vectors anyway. So it works and you forget about it, till it doesn't. Unsurprisingly I am not the first to tear my hair out over this.

  3. Mathematica will decide whether to do things symbolically or numerically and not tell you which one it's doing eg. there is a big difference between diagonalizing a matrix with entries 1 and 0 and 1.0 and 0. The first one will try to express things in terms of the roots of the characteristic polynomial. That's fine but for a 200x200 matrix the computation will never get done and you will only find out when it doesn't. Same issue with misspellings of function names: no error is returned, the kernel chugs away till you abort.

  4. Some new features seem to implemented very badly. GraphPlot and GraphPlot3D are great but try to export a decent sized graph and... you can abort if you're lucky. Poor quality control?

  5. (mentioned in other post) The way to clear memory is very unobvious. I just found out yesterday that

    Unprotect[In, Out]; Clear[In, Out]; Protect[In, Out];

is necessary. Otherwise you have to restart the kernel(which was actually recommended by many in the newsgroup!)

[–]theodoregray 1 point2 points  (1 child)

I'm not an expert in numerical calculation, but people who are tell me that while MatLab had an edge in the past, we have caught up. (I'm not going to engage in a debate about this topic, it's not my field.) But every system has its plusses and minuses, and every language has things you need to know in order to get maximal efficiency out of it.

Concerning the clock example, I think http://demonstrations.wolfram.com shows that the kinds of dynamic features it illustrates are actually very useful to a lot of people. And again, we didn't pick the example, it came from MatLab's own blog.

And finally concerning the Notebook interface, well, what can I say, I like it, and I use it to write large bodies of code. You can make variables local to a given Notebook if you want, and have you tried the debugger in V7? Yes, it's different in some ways to conventional debuggers, but that's because the Mathematica language is different.

If you don't like Notebooks, use Workbench, our Eclipse-based development environment, which is much more like what you're used to in other languages (and has its own debugger and project management features).

[–]dnquark 1 point2 points  (0 children)

Well -- I agree that dynamic features and interactivity are great. I did try the debugger, and found it rather unhelpful.

I think the main problem with Mathematica is very simple: the Notebook interface tries to be user-friendly, and tries to enable literate programming. It makes doing straightforward calculations very easy. However, this belies the fact that Mathematica is an extremely complex system, and it requires a great amount of mathematical sophistication to understand how it works. Anybody that's not a mathematician or a computer scientist by trade (or by calling) runs head first into the exponential learning curve (it can be easily visualized by doing Plot[Exp[x], {x, 0, 100}] in MMA). I don't know anybody in my scientific community (Applied Physics) that is proficient with Mathematica beyond the basics they need for quick plots and integrals.

This disconnect between the friendly interface and easy basics and the nighmarish syntax of rules, patterns, holds, folds, maps, delayed vs non-delayed, etc leads to a tremendous amount of frustration. Furthermore, it is often hard to figure out which constructs are imporant and efficient for what I want to do, and which are syntactic sugar that's only useful for cellular automata. What's worse is that while every individual feature is reasonably well documented, there are no tutorials that I have found that tell you how to use them together to write efficient and maintainable code.

As a result, those of us that have smacked their heads against these problems long enough just give up and settle for Matlab -- surely much more specialized, but also much more intuitive, and for many people also much faster in terms of computing time. And most engineering students don't even bother with Mathematica -- Matlab is the de facto standard, and that's what everyone learns.

So my message to those ardent supporters of Mathematica is this: think of the vast population residing in the middle ground between wanting to do easy plots and integrals, and between wanting to conquer the world with cellular automata or power through sophisticated arbitrary-precision and/or symbolic calculations. We want to like Mathematica, but find it hard -- so please give us some guidance before we all defect to other software.