To be more clear: First I think the ideas in this thread will be used
in Julia projects in interesting ways we aren't even thinking of---
it's well suited for all of them. At the moment, I'm only interested in
implementing a pattern and rule based system something like
Mathematica. An example of why, is the Rubi integration package
http://www.apmaths.uwo.ca/~arich/
The author claims that it "dramatically out-performs Maple and
Mathematica". I have not tried
to verify this, but it is a serious project. It is written entirely with Mma
rules. It does not use Mma's integration system at all. Fateman's code
can employ at least a subset of these rules.
http://www.cs.berkeley.edu/~fateman/lisp/mma5max/rubi/
As far as I can see in mma5max, all expressions, including patterns and
rules,
are maintained as singly linked lists during the whole procedure. It's
probably quite a bit slower than Mma running Rubi. But, if you build
a CAS in Julia based on DataTypes representing mathematical objects,
it will have to be developed for a very, very, long time before it can
integrate like Rubi. Of course, like I already said, there are things
that Mathematica is inherently bad at. And other things, like tight
integration with the host language, might be more important for some
applications that being able to to 50K integrals.
Even if I or someone else, got the all the basic pattern matching
implemented, Rubi (for instance again) still uses Simplify and other
features. I imagine it would be very big project to develop to the
point of handling all the Rubi rules. Still, I am really surprised by
how quickly I was able to get as far as I have and how non-dismal the
performance is, even though I made no attempt to optimize the code at
any level.
--John
On 01/26/2015 07:20 PM, Francesco Bonazzi wrote:
> On Monday, January 26, 2015 at 6:57:48 PM UTC+1, James Crist wrote:
>
>
> Side tracking a bit, but one of the reasons I use SymPy instead
of something like Maxima is that it meshes seamlessly into the language
infrastructure. By writing a parser and creating another system means
that it can't use julia's ecosystem without modification. I'd rather see
a CAS work within Julia's parser framework. But that's just me.
>
>
> A Mathematica parser could be used as an optional addition, such as
what Mathics is to SymPy.
>
> Anyways, there are various options for Julia:
>
> use Expr and operate on them, this is similar to how Maxima works.
> declare symbolic types and use operator overloading: this is the
approach by SymPy and Axiom.
> create a DSL invoked by a macro, this appears to be the case for
SJulia.
>
