Mathematica

Andrew Coppin

11 May 2007 11 May '07

10:26 a.m.

Hi folks. How difficult would it be to implement Mathematica in Haskell? I mean, I really like Mathematica, but it costs over £2,000. I can't really afford to pay that much for something that's only really a "toy". (It's not like a *need* it for anything, I just like playing with it.)

Show replies by date

Joe Thornber

11 May 11 May

10:37 a.m.

On 11/05/07, Andrew Coppin wrote:

...

Hi folks.

How difficult would it be to implement Mathematica in Haskell?

The language itself; very easy I'd say. The maths libraries ... years. So if you just want something to play with I'm sure you could get something working quickly. I'd be interested in helping out. - Joe

Henning Thielemann

1:08 p.m.

On Fri, 11 May 2007, Joe Thornber wrote:

...

On 11/05/07, Andrew Coppin wrote:

...
Hi folks.

How difficult would it be to implement Mathematica in Haskell?

The language itself; very easy I'd say. The maths libraries ... years. So if you just want something to play with I'm sure you could get something working quickly. I'd be interested in helping out.

You know that already years have gone into Haskell computer algebra: http://www.haskell.org/docon/ ?

Rene de Visser

5:01 p.m.

...

How difficult would it be to implement Mathematica in Haskell?

Why don't you use axiom? It already has several 100 of years man effort put into it. Or for dynamically type package you could use Maxima. Both are free. Rene.

Dan Piponi

5:36 p.m.

There are two aspects to mathematica. There's the core language and there is the library of functions made available to the user. The library is many lifetimes of work so don't even think about doing more than a fraction of a percent of it on your own! The core language is more straightforward but it still has a fairly sophisticated backtracking pattern matcher. To get the core language working you need to implement at least some algebra - for example the pattern matcher understands commutativity, associativity and the notion of an identity for a binary function. Many years ago I implemented a useful subset of the core language myself using C and stack based continuation abuse for the backtracking. (Good enough to be able to type in lots of standard integrals from Abramowitz and Stegun and combine them with the all the standard high school techniques for integration.) It took several months of hacking in my spare time to get it working (back in the days when I had a lot of spare time). I expect that in Haskell it would be much easier, especially using a suitable non-determinism monad for the pattern matching. The pattern matcher was probably the largest component of the work. Haskell has some great features that Mathematica doesn't and it'd be nice to see those features in an algebra package. In particular: lazy evaluation and static types. I'd probably also want dependent types. Aldor/Axiom does the types part already. -- Dan On 5/11/07, Andrew Coppin wrote:

...

Hi folks.

How difficult would it be to implement Mathematica in Haskell?

I mean, I really like Mathematica, but it costs over £2,000. I can't really afford to pay that much for something that's only really a "toy". (It's not like a *need* it for anything, I just like playing with it.)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Andrew Coppin

6:48 p.m.

...

How difficult would it be to implement Mathematica in Haskell?

OK, you'll be glad to know I wasn't entirely serious when I wrote that. ;-) There are 4 conceptually seperate aspects to Mathematica. - First, there is the absurdly efficient arbitrary precision number crunching engine. It can run parallel, it handles sparse matricies the size of a small planet, and so forth. - Second, there is the user interface, with nice maths typesetting, graph plotting, and (new in v6) animation features. - Third, there is the Mathematica programming language. It's similar to Haskell in many ways - and different to it in any other ways. - Finally, but not least, there is a code library the size of a small star system implementing just about every function, identity, algorithm, optimisation and statistic known to human kind. Obviously that last part cannot ever be duplicated - hell I don't even know what a hypergeometric function *is*, much less why you'd care about it. I certainly couldn't implement it, never mind implement it efficiently. I think part of the reason Mathematica costs so damn much is the decades of R&D that Wolfram Research has poured into the system (and indeed continues to pour into it). That's one Very Big Library! So, I can't copy the giant code library. But then, given that I don't know what a hypergeometric function is, will it matter if I can't use one? Not really, no. The absurdly efficient number crunching is obviously not implementable in Haskell - or indeed virtually any language except assembly. Haskell (or at least GHC) already has bignums from the GMP, so arbitrary integers are quite efficient already. That'll have to do. The pretty user interface is obviously not implementable in Haskell. (Probably the closest you could get is to write something in XUL, run it in Mozilla and get it to talk to the Haskell computation engine.) And that leaves the Mathematica programming language. Well, it has some baroque syntax in places. But beyond that, it's basically a graph reduction system, like Haskell. Unlike Haskell, it's not statically typed. And the pattern matching is far more general. It seems it would be a fairly difficult task to implement the pattern matching engine properly. Alternatively, you could just "cheat" and write a program that recognises a hard-coded range of patterns and transforms them. Personally, I'd prefer to do things the way Mathematica does... Aaaanyway, maybe next time I'll wait until April 1st before posting a message like this. ;-) [Hmm... we should add the quote above to the humour pages or something!]

Dan Piponi

8:58 p.m.

On 5/11/07, Andrew Coppin wrote:

...

It seems it would be a fairly difficult task to implement the pattern matching engine properly.

Not 'difficult' as in "nobody ought to try this in Haskell" but 'difficult' as in "it seems like a task well suited to Haskell, would be worth the effort even though it might be quite a challenge to complete, and Andrew Coppin really ought to get started on it right away". :-) -- Dan

Andrew Coppin

9:03 p.m.

Dan Piponi wrote:

...

On 5/11/07, Andrew Coppin wrote:

...
It seems it would be a fairly difficult task to implement the pattern matching engine properly.

Not 'difficult' as in "nobody ought to try this in Haskell" but 'difficult' as in "it seems like a task well suited to Haskell, would be worth the effort even though it might be quite a challenge to complete, and Andrew Coppin really ought to get started on it right away". :-)

Hahahaha! Well, to quote Agent Brown from The Matrix, "It has already begun..." ;-) One more project to add to my list of stuff that never actually gets finished! Heh. So far Indoculate and Chaos are the only things that have resulting in runnable code - and considering the number of projects I've begun now...

Chung-chieh Shan

13 May 13 May

12:44 p.m.

Andrew Coppin wrote in article <4644BA82.4010202@btinternet.com> in gmane.comp.lang.haskell.cafe:

...

The absurdly efficient number crunching is obviously not implementable in Haskell - or indeed virtually any language except assembly. [...] The pretty user interface is obviously not implementable in Haskell. [...] It seems it would be a fairly difficult task to implement the pattern matching engine properly.

Why? -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2007-05-15 International Conscientious Objection Day http://wri-irg.org/

Andrew Coppin

1:19 p.m.

Chung-chieh Shan wrote:

...

Andrew Coppin wrote in article <4644BA82.4010202@btinternet.com> in gmane.comp.lang.haskell.cafe:

...
The absurdly efficient number crunching is obviously not implementable in Haskell - or indeed virtually any language except assembly. [...] The pretty user interface is obviously not implementable in Haskell. [...] It seems it would be a fairly difficult task to implement the pattern matching engine properly.

Why?

Writing *insanely* efficient number chrunking software requires a deep understanding of the target architecture, and lots of playing with very low-level constructs. Assembly is really the only language you can do it with; even C is probably too high-level. The "notebook" interface is very sophisticated and clearly beyond the capabilities of any current GUI toolkit for Haskell. (Implementing this would be approximately as hard as writing a full web browser in Haskell.) The pattern matching engine could be implemented, but it's not a trivial task. Mathematica's pattern matching is quite sophisticated. It would take someone a while to do, that's all.

Tomasz Zielonka

12 Jun 12 Jun

5:41 p.m.

On Sun, May 13, 2007 at 02:19:55PM +0100, Andrew Coppin wrote:

...

Writing *insanely* efficient number chrunking software requires a deep understanding of the target architecture, and lots of playing with very low-level constructs. Assembly is really the only language you can do it with; even C is probably too high-level.

The "notebook" interface is very sophisticated and clearly beyond the capabilities of any current GUI toolkit for Haskell. (Implementing this would be approximately as hard as writing a full web browser in Haskell.)

The pattern matching engine could be implemented, but it's not a trivial task. Mathematica's pattern matching is quite sophisticated. It would take someone a while to do, that's all.

Thanks, that's exactly what we need - someone telling it's impossible motivating somebody else to prove it isn't ;-) BTW, how do you know that Mathematica's number chrunking software is written in assembler? Do they brag about it? Best regards Tomek

Jon Harrop

6:05 p.m.

On Tuesday 12 June 2007 18:41:34 Tomasz Zielonka wrote:

...

On Sun, May 13, 2007 at 02:19:55PM +0100, Andrew Coppin wrote:

...
Writing *insanely* efficient number chrunking software requires a deep understanding of the target architecture, and lots of playing with very low-level constructs. Assembly is really the only language you can do it with; even C is probably too high-level.

Just reuse existing libraries: BLAS, LAPACK, ATLAS, FFTW. The free libraries that I have benchmarked were all much faster than Mathematica. FFTW was 4x faster on average, for example.

...

...
The "notebook" interface is very sophisticated and clearly beyond the capabilities of any current GUI toolkit for Haskell. (Implementing this would be approximately as hard as writing a full web browser in Haskell.)

Yes. Our technical presentation software took 6 man months but it supported antialiasing, real-time visualization and zooming and panning of the whole GUI. A simple notebook interface rendering to OpenGL would only be ~20kLOC of OCaml/Haskell.

...

...
The pattern matching engine could be implemented, but it's not a trivial task. Mathematica's pattern matching is quite sophisticated. It would take someone a while to do, that's all.

Beyond the pattern matchers in ML and Haskell, Mathematica adds sequence patterns. These just search linear sequences or permutations completely naively. For example, the obvious implementation of the higher-order map function has quadratic complexity because Mathematica eagerly copies entire sub arrays "t" unnecessarily: map[_, {}] := {} map[f_, {h_, t___}] := Prepend[map[f, {t}], f h] Moreover, it does no decision-tree optimizations. Instead, it only optimizes patterns in the symbol table (called "DownValues") that contain only single static symbols into a hash table (called a "dispatch table"): f[a] = 1 f[b] = 2 ... There are some undocumented tricks but you can achieve the same asymptotic performance quite easily, e.g. hashconsing and memoization. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e

Jacques Carette

9:43 p.m.

Jon Harrop wrote:

...

On Tuesday 12 June 2007 18:41:34 Tomasz Zielonka wrote:

...
On Sun, May 13, 2007 at 02:19:55PM +0100, Andrew Coppin wrote:

...
Writing *insanely* efficient number chrunking software requires a deep understanding of the target architecture, and lots of playing with very low-level constructs. Assembly is really the only language you can do it with; even C is probably too high-level.

Just reuse existing libraries: BLAS, LAPACK, ATLAS, FFTW. The free libraries that I have benchmarked were all much faster than Mathematica. FFTW was 4x faster on average, for example.

You must have done benchmarks with very low numbers of precision, which is really boring and for which Mathematica is overkill. If you are interested in numerical computations that require arbitrary precision, then Mathematica (I have to admit) is seriously good: http://www.cs.ru.nl/~milad/manydigits/results.php Note how, for all the 'easy' problems, it beats every competitor hands-down. And how they did not even given entries for any of the 'hard' ones! Jacques

John Meacham

12 May 12 May

12:05 a.m.

On Fri, May 11, 2007 at 11:26:42AM +0100, Andrew Coppin wrote:

...

Hi folks.

How difficult would it be to implement Mathematica in Haskell?

I mean, I really like Mathematica, but it costs over £2,000. I can't really afford to pay that much for something that's only really a "toy". (It's not like a *need* it for anything, I just like playing with it.)

You might want to try maxima http://maxima.sourceforge.net/ and TeXmacs http://www.texmacs.org/ for a nice and open source CAS solution. A TeXmacs interface to ghci might be a fun project if someone were bored and would certainly spice up the screenshots on the ghc page. :) John -- John Meacham - ⑆repetae.net⑆john⑈

6600

Age (days ago)

6632

Last active (days ago)

List overview

Download

13 comments

10 participants

participants (10)

Andrew Coppin
Chung-chieh Shan
Dan Piponi
Henning Thielemann
Jacques Carette
Joe Thornber
John Meacham
Jon Harrop
Rene de Visser
Tomasz Zielonka

Mathematica

Andrew Coppin

Joe Thornber

Henning Thielemann

Rene de Visser

Dan Piponi

Andrew Coppin

Dan Piponi

Andrew Coppin

Chung-chieh Shan

Andrew Coppin

Tomasz Zielonka

Jon Harrop

Jacques Carette

John Meacham

tags

participants (10)