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
Else
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.
GUIs 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 |
