About us...
Site Map

ruby in steel


Maple 10 $1,995 / £1,325 (ex VAT)
http://www.maplesoft.com/ :: http://www.adeptscience.co.uk/

Mathematica 5.2 $1,880 / £1,625 (ex VAT)


Power Of Two

Given the choice - Mathematica or Maple – which should you go for?
Dermot Hogan figures it out…

There are two major, widely available, symbolic mathematical computer systems – Maple and Mathematica. Both have recent new versions with Mathematica 5.2 and Maple 10, the latter being a major upgrade. The question is which one to use?

The answer to that question is not all that straightforward. Before Maple 10, I would have said that Mathematica would be the preferred choice: Maple didn’t have the same level of graphical user interface and text formatting capability. But Maple has been given a major facelift with version 10. It’s been transformed by the addition of standard GUI components such as sliders, combo boxes and so forth and it has gained a set of other useful presentation tools.

"In this review, I’ll look at how I used Mathematica and Maple to solve a real-life problem..."

The latest Mathematica upgrade from 5.1 to 5.2 is relatively minor by comparison. Wolfram has concentrated on incorporating 64-bit computing and multi-core processing. This is probably of great significance if you are modelling climate change, but I suspect that, for the great majority of Mathematica users, it won’t exactly induce an irresistible urge to upgrade.

If you search the Web for reviews of Maple or Mathematica, you tend to find that they are either written by university mathematics and engineering departments as an aid for training students or by magazine journalists zipping through the “ten minute tour” introductions to both packages (been there, done that!). However, that doesn’t really help you choose which one to buy.

Mathematica can produce very nice graphs and images (left). But Maple with it’s 3D ‘grab-and-rotate’ feature (right) is superior.

In this review, I’ll look at how I used Mathematica and Maple to solve a real-life problem. Now, I want to emphasise that this isn’t an extensive test – it simply isn’t possible to evaluate each package point by point. Mathematics is a vast subject and in a review of just a few thousand words no-one can summarize even a small subsection of the topics addressed by these two packages. Remember, each package has several thousand mathematical functions embedded, helping you to solve problems in subjects from Diophantine equations to partial differential equations.

My background is mathematical physics – that’s what I was trained in. So the questions I tend to deal with come with that slant. If your particular mathematical bent is elliptical equations or statistics then too bad. Maybe you’ll have to write your own review… ;-)

A Real Life Test

I wanted to settle - at least in my own mind - a dispute on an Internet news group over a telescope’s characteristics. Bear with me while I explain what the problem is. In many telescopes, light from the main mirror – the ‘primary’ - is delivered to the eyepiece via a secondary optical system – the ‘secondary’. The secondary blocks some of the light from the primary – it casts a shadow - and so a large secondary obstruction is undesirable.

The question was whether a particular telescope’s obstruction was 35% or 42%. The manufacturer claimed that it was 35% while evidence was submitted to the news group that it was 42%. The evidence in question was a photograph of a star taken through the telescope with the eyepiece at maximum extension in the focuser. It seems that it is commonly accepted wisdom (at least on the Internet) that you can accurately determine the central obstruction’s size by doing this – and indeed I was told very dogmatically that this was so. Being an argumentative type, I didn’t think that this was the case and I set out to prove it.

The first thing I did was locate some theory on diffraction (Algorithms for Fresnel Diffraction at Rectangular and Circular Apertures [pdf] ). Recommended reading for the small hours, I can assure you! With a telescope, the diffraction pattern produced by the wave nature of light when the telescope eyepiece is at focus is simple ‘Fraunhofer’ diffraction. A long way off, and you see the aperture of the telescope with the shadow of the secondary clearly obstructing it – you might call this the ‘geometric’ case. And in between is ‘Fresnel’ diffraction.

The trouble with Fresnel diffraction is that it is tricky to compute. Indeed, before the advent of fast computers and packages like Maple and Mathematica, it just wasn’t computed. For a circular aperture, the computation involves a complex oscillatory integral with Bessel functions which can only be evaluated by numerical methods.

So, over first to Mathematica

After a bit of work and graphing, out popped the answer: with the eyepiece at maximum distance from the focus, the measured size of the central obstruction’s shadow was indeed 42% for a 35% physical obstruction. In other words I was right. Well, that makes a nice change!

Mathematica handled this integral well. It did issue warnings about “slow convergence”, “failed to converge after n iterations”, etc., so I could see what was going on. Now with a bit of parameter adjustment, I was able to get the integral to converge sufficiently to get better and better answers with no warnings. I could alter the type of numerical integration technique to try and get a faster convergence and also alter both the “working precision” and “result accuracy” of the calculation to get a feel for how things were going. As I increased the oscillation parameters, it took longer – as you’d expect – but it did get there.

Here you can see that Mathematica is complaining about the integral, but in a sensible way. The integral evaluated ok when I set the MaxRecursion parameter to 20.

Maple on the other hand, was fine – but only up to a point. I could not alter the integral method to, say, Monte Carlo (as I could in Mathematica) and the only other variable I could tweak was the accuracy. Maple was quite a bit slower than Mathematica. But the big problem I had with Maple was that, at some point, it decided that it couldn’t handle the integral at all. I started in Maple by setting the oscillatory Bessel function to vary quite slowly and Maple handled the integral well giving exactly the same answers as Mathematica. However, as I increased the oscillation frequency, Maple just gave up.

Maple had difficulty handling this integral. This is the default output – not very helpful.
I found that I could get Maple to evaluate this integral by increasing the Digits parameter – but the execution speed was way too slow.

It didn’t issue any warning messages; instead it returned the symbolic form of the integral. This is Maple’s way of saying “integral didn’t converge”. It’s possible to trap this condition in a procedure by testing if the answer is numeric or not, but it’s not that friendly if you are trying to do a simple graph of the function.

A further issue with Maple on this particular numerical integration was the speed. The difficult bit of the integration is in a rapidly varying Bessel function. I set the ‘speed of oscillation’ to a low value of 1000 and ran the integration in both Mathematica and Maple. Maple took 30 seconds, while Mathematica’s response was almost instantaneous. Upping the parameter to 10,000 took Maple 125 seconds, and Mathematica nifty 8 seconds. On to 50,000 and Maple gave up. I couldn’t find a way of getting it to do the business, no matter what I did. With Mathematica, it took 50 seconds. I continued to increase the oscillation parameter and Mathematica continued to evaluate the integral at parameter values of 300,000 and above required to solve this particular diffraction problem. At this value it took 350 seconds per integration.

I emailed Maple’s technical support and got a quick “we’re looking at it response” (not bad). After a day or so, Maple responded with a solution: set the number of working digits to 100 (that is a lot of digits). This took over 700 seconds to give the same answer as Mathematica did in 50. Maple support did admit to a “weakness in Maple’s numeric integration algorithm with respect to oscillatory integrands” and acknowledged “… the computation takes longer than it should. Our development team will work to address this weakness for an upcoming release of Maple.”

As a final test, I then tried setting the parameter to 300,000 to compare with Mathematica: Maple did not evaluate the integral.

Again, I’d like to emphasise that this was one particular problem in one small area of mathematics of interest to me (and probably no-one else). You just can’t apply the conclusions to the whole of Mathematica and Maple. In some areas, no doubt, Maple will perform better than Mathematica, but in this area, I found Mathematica clearly to be better.

Functional vs. Procedural

But irrespective of the performance of Maple and Mathematica in specific problems there are two areas where there are fundamental differences in how the packages work: the programming language and the user interface or GUI.

First, I’ll look at programming. By programming, I mean writing something longer than one line of code to evaluate some mathematical construct. In both systems, you can write entire subsystems as add-ons involving many thousands of lines of code; but for most users, I should think, a program might be a little less ambitious.

At first sight, the way Mathematica approaches this looks a bit odd. The If statement, for example, looks suspiciously like a function:

z = If[z > 2, 2, 0];

In fact, it is a function! The Mathematica programming language is a ‘functional’ language. In a normal ‘procedural’ language like C or Visual Basic you might write:

If z > 2 Then
   z = 2
  z = 0
End If

But not in Mathematica: the If statement is a function with three arguments and returns a value. The Mathematica formalism is much more concise than the equivalent procedural code. But there’s a downside – you can write obscure code amazingly quickly.

Mathematica uses a ‘functional’ language to extend its basic operations. This can be concise, but obscure – even to the person who wrote it.

There are a couple of things I’ve discovered about functional programming. Up front, the technique is wonderful for prototyping something or trying things out. The ability to work fast and enter things quickly is a great asset if you are ‘playing around’ with some maths. The second thing is that, unless you liberally comment your work, in two weeks’ time you will not have a clue what you were doing. It never ceases to amaze me how something that I wrote in Mathematica’s functional way (and which made perfect sense at the time) looks like the scribblings of a maniac some time later.

In complete contrast, Maple is procedural. The language might look slightly different from Pascal (which it resembles), but a Maple procedure will be more or less immediately understood by any competent programmer, even if they don’t have a mathematical background. Entering a procedure in Maple is certainly a longer process than in Mathematica. It’s made worse by the necessity to terminate each line with Shift Return; otherwise the procedure is evaluated if you simply press Return at the end of a line. Oddly enough, Mathematica is exactly the opposite. You enter a Return to move to a new line and Shift Return to evaluate the whole cell. I’d often wondered why Mathematica did it this way round. Having worked with the two, I’d say that Mathematica’s way it’s better and more logical than the Maple style. However, that’s strictly a personal view.

Programming Maple might be more familiar if you are used to languages like Visual Basic, Pascal or C.

But the big plus about the Maple language is that it has a debugger! If you are used to a procedural approach to computer languages, then the first thing you look for is the debugger. In my experience, the ease with which you can stop a procedure at a specific point, poke around, scratch your head and think is vital to the speed at which you can progress. Especially with the more complicated stuff.

The Maple debugger is pretty good too, even if it isn’t up to Visual Studio standards. You can set a breakpoint, examine variables, step into procedures, evaluate expressions on the fly and so on.

The Maple debugger is very useful in developing mathematical procedures.

In Mathematica, on the other hand, you can add a Print statement to help you. Yes, I’ll repeat that: you generally debug by using a Print statement – at least, I do. There is no debugger. It’s true that there are packages around that add some debugging capabilities – but they are external. In the core of Mathematica, there just isn’t anything very much better than a Print. The recommended technique of using the Trace function often produces far too much output to be useful. Wolfram Research informs me that a debugger is being developed and we shall aim to bring you a review of this as soon as it is available.

Contrasting the two approaches, I find Mathematica better for trying things out, but I sure wouldn’t want to maintain any heavyweight Mathematica code. Also, the lack of a Mathematica debugger is a serious omission. Entering code in Maple is more long winded (and as I’ve said, the way Shift and Return work is the wrong way round to may taste), but it’s easier to see what’s going on and a lot easier to debug.


I’ll start here by looking at the Maple GUI interface. Maple 10 has a fair number of new features and it lets you put simple GUI controls such as text boxes, combo boxes and the like into a Maple worksheet. Initially, I found this to be a little confusing as I was expecting something like Visual Studio or Delphi in which you simply drag-and-drop controls onto a canvas.

It’s not quite like that. You do indeed drag and drop controls from a palette into the input area of the worksheet, but there’s no real ‘canvas’ there. It’s still a good old Maple worksheet underneath and you have to be careful where you drag the controls to: I ended up accidentally nesting textboxes, for example, when I attempted to construct a ‘form’. It just doesn’t work that way – controls are stacked next to one another by default, but you can do simple layouts using a grid control. I can’t really figure out why Maple didn’t go the whole hog and do a canvas implementation with events driving the Maple mathematics. It can’t be that difficult to do.

Maple’s ‘maplet’ tools allow you to construct simple GUI based applications by attaching elements of Maple code to Windows style controls. While it’s not Visual Studio, it’s not bad either.

Whatever the limitations of the Maple GUI (and to be fair, you aren’t going to be writing a ticketing system in Maple), it’s still a lot better than the corresponding ‘GUI’ - or lack of it - in Mathematica.

Mathematica is designed and built round the concept of ‘notebooks’ – visual representations of the underlying Mathematica code. A notebook (roughly speaking) consists of a set of nested cells with code and layout information attached. With recent versions of Mathematica, you can display HTML or TeX in addition to the standard Mathematica notation. Very powerful and useful it is too – but it isn’t a GUI, at least as far as I understand the term. Mathematica includes an add-on called GUIKit and with this you can construct and use a slider, for example.

However, it isn’t easy to use. The example given shows over a dozen lines of code – just to set up a simple slider. It reminds me of the early days of GUI programming in Windows – you had to type (or paste in, really) hundreds of lines to code to get a simple “hello world” message to appear.

While you can use standard GUI controls in Mathematics, it’s not exactly point and click.

The fundamental problem with Mathematica’s notebook approach is that it was fine - revolutionary, even - when it was introduced on the NeXT workstation in 1988. But the world has moved on: it’s 2005. These days, I might expect to be able to attach some code to a button, modify its parameters with a slider, upload some data parsed from a web page on the other side of the world, link it with data from my relational database and squirt out the results as a PDF file. You can probably do all this in Mathematica – but it isn’t easy or intuitive.

You might argue that you can’t do the above in any other system. You’d probably be correct – at the moment. But soon it will be possible. It seems to me that Maple has moved much further in this direction than Mathematica. There are a number of Maple ‘assistants’ built into the program that help with boiler plate tasks like building a graph. The Maple front end now has a simpler and much more intuitive feel to it – rather like MathCad, really. I’ll be interested to see how Mathematica evolves in its next major release.

Maple still has the upper hand in graphics. I particularly like the ability to rotate a 3D graph by dragging it.


It’s impossible to come to a generic conclusion about which package is better overall. In the one area of mathematics I looked at, Mathematica beat the pants of Maple both in speed and capability. However, I have to emphasise once again that you cannot apply this result to the packages as a whole: I wouldn’t be too surprised to find Maple running Mathematica into the ground in another area.

In programming languages, after some thought and experimentation, I’ve found the Mathematica approach to be the better for rapid prototyping and exploration. But if you are a procedural programmer from, say, an engineering background, then the Maple procedural language may suit you better. Also, the existence of a reasonable debugger in Maple is a big plus. From personal experience, I can tell you that debugging Mathematica Notebooks can be both time consuming and frustrating.

In terms of the GUIs and the front end, I found Maple to have the advantage. The existence of easy to use Windows style controls makes the construction of good user interfaces decidedly easier – even if it’s still constrained by the underlying Maple worksheet.

Mathematica 5.2
for more information on this award, see HERE

Given the choice between Mathematica and Maple, and with only enough money to buy the one, I’d have to go for Mathematica. In the area that I’m interested in, Mathematica was definitely the faster and more capable and, with my personal preference for a functional language approach, I find it easier and quicker to program. Surprisingly, it’s slightly cheaper too – but only if you purchase in US dollars.

Here’s the result of all my hard work. This is a Fresnel diffraction pattern (in Mathematica) which gave the answer to the problem. The graphing may not be as pretty as in Maple, but I did get a solution.


Mathematica and Maple pricing varies quite a bit depending on whether you are a full time student, a commercial organisation or a government. The standard price for Mathematica 5.2 in the UK is £1,625 going down to £80 for a student. In dollars, the price is $1,880 for the standard license and $140 for the student.

For Maple, a commercial licence is £1,325 in the UK going down to about £60 for a student. In dollars, the corresponding prices are $1,995 and about $90.

Mathematica CalcCenter 3 is much more competitively priced at £515 or $595... for the standard edition and £70 or $100 for the student licence.

Dr Dermot Hogan holds a Ph.D in physics from the University of Cambridge. A specialist in realtime trading technologies, he is currently developing telescope guiding, imaging and control systems.





October 2005


Home | Archives | Contacts

Copyright © 2006 Dark Neon Ltd. :: not to be reproduced without permission