[Haskell-cafe] Implementing Mathematica

Andrew Coppin andrewcoppin at btinternet.com
Thu May 31 16:12:22 EDT 2007


jerzy.karczmarczuk at info.unicaen.fr wrote:
> The conditions of its career were far from obvious. The World had many
> symbolic math packages: Reduce, Macsyma, Schoonschip (beloved by high-
> energy physicists), Maple, Scratchpad2/Axiom, later MuSIMP/MuMATH for
> small platforms, etc.

I find that statement interesting. I have never come across *any* other 
package that can perform _symbolic_ mathematics.

(Sure, there are packages that can perform specific operations - solving 
certain kinds of equations, transforming matricies, rearranging 
formulas. But I have never seen any other package where you can just do 
*anything*.)

> * First symbolic packages treated *first* the symbolic expressions as
> something to be evaluated/simplified. One sees that Maple has been built
> on this principle.
> Mathematica changed a bit the perspective, along - perhaps - the same
> lines as Schoonschip, where the fundamental stuff was *rewriting/
> transformations*. So, Mathematica since the begininng was equipped with
> a very powerful pattern-matcher/substitution contraption. For the sake
> of efficiency it was less powerful than a general unifier, but it was
> really nice (and it existed already in SMP, before the birth of
> Mathematica). Now, again, somebody would do that in 4 days??
> The semantic pattern-matcher within an algebraic package, is worlds
> apart from the syntactic/structural pattern-matcher of Haskell.
> This helped a lot to popularize Mathematica, and has been shamelessly
> abused in the advertising, where our friends used to say "we DO
> MATHEMATICS with computers". Non-sense, of course...

Pattern matching *so* rich, in fact, that you can even use it to do 
things that aren't mathematics - although the default input syntax isn't 
really geared to it.

But yes - I have tried to implement that pattern matching engine a 
couple of times in Pascal. (Remember Pascal?)  Getting it to work for a 
few test cases is easy. Getting it to *properly* handle associativity 
and commutivity is really nontrivial. (I mean *really* nontrivial! Or 
perhaps I am an inferior programmer - one of the two!)

> * All the numerical, standard stuff, the interface between the symbolic
> and the numerical functions, with plots 2D/3D, etc. Too often people
> speak about that, comparing, say, Matlab with Mathematica (while Matlab
> has no symbolics, etc.)
> Here the Mathematica team did a serious, thorough job, trying to adapt
> the richness of this layer to many branches of science and engineering.
> It was mainly a compilation process, they hardly added anything new, but
> made a coherent, useful library. Won't repeat it in 4 days, or even in
> 4 months.

Again, Mathematica has all these functions defined, it has vast 
*libraries* of identities for transforming them, *and* it has efficient 
numerical algorithms to compute them. (If you believe the product 
literature, for many functions there are several different possible 
algorithms depending on how accurate you want it, what arguments you're 
trying to compute it on, etc.) I really don't see anybody easily 
duplicating all this...

> =====================================
> Is there any sense in "making Mathematica with Haskell"? As a package,
> most certainly no, too much to implement, for what? In order to have
> another tool of the kind which already exists?

...other symbolic math tools exist?



More information about the Haskell-Cafe mailing list