Symbolic Math: try a translation of Axiom to Julia?

3,279 views
Skip to first unread message

Francesco Bonazzi

unread,
Mar 1, 2014, 3:41:19 PM3/1/14
to juli...@googlegroups.com
I have read of discussion of implementations of Computer Algebra Systems on this discussion in the past. I would like to propose a solution which avoids having to reason with the logic of mathematical algorithms.

Axiom is a FOSS computer algebra system, started in 1971, released under the New BSD license in 2001. Since 2007 it has been forked into two projects: FriCAS and Open-Axiom.

http://en.wikipedia.org/wiki/Axiom_%28computer_algebra_system%29

Axiom is written in its own programming language, called SPAD. It is both object-oriented and functional, probably inspired by Lisp. SPAD has been the basis for Aldor, its direct heir, which has more documentation available on the internet (SPAD and Aldor are very similar in their syntax). Technically, Axiom is written in literate programming (LaTeX with code blobs), it is therefore well-documented.

I had a look at Axiom's source code, I think that SPAD has many logical similarities with Julia. Axiom defines mathematical objects (monoids, rings, fields, etc...), functions in SPAD support type-overloading and parametric types (these ones are extensively used). Object methods are defined in a way similar to Julia, even operator overloading supports both forms +(a, b) and a+b.

A possible concern may be SPAD's domains and categories. Roughly speaking, domain is similar to Julia's types with operators overloaded, while categories are abstract types. Unlike Julia, SPAD categories define the methods that domains inheriting them have to implement, so categories look like Java's interfaces or abstract classes.

http://en.wikipedia.org/wiki/Aldor

(by the way, I am wondering whether some of Julia's developers got inspired by Aldor, or whether it is just a coincidence).

The advantages of translating Axiom into Julia are primarily:
  • Julia would have its own Computer Algebra System as a package (example of usage: enable some kinds of symbolic optimization).
  • Axiom has currently few people developing it, due to the steep learning curve of the SPAD programming language (it has very little documentation on the internet, and it is used only in Axiom). Translating Axiom to a more common language would probably boost its development rate, as new developers would find it easier to contribute.
  • Both FriCAS and Open-Axiom are developed on Sourceforge, github would be a more comfortable website.

Maybe a collection of regex could be sufficient to translate Axiom's code (save for possible complications).

Axiom has many mature algorithms, it can symbolically differentiate, integrate, solve ODEs, solve equations and so on. It is still not as powerful as Mathematica.

Stefan Karpinski

unread,
Mar 1, 2014, 4:33:24 PM3/1/14
to juli...@googlegroups.com
Any similarity with Aldor is entirely accidental. I've never heard of it before.

Alan Edelman

unread,
Mar 1, 2014, 6:26:26 PM3/1/14
to juli...@googlegroups.com
Hadn't heard about axiom in a while.  I still remember the days of Dick Jenks and scratchpad.
I played with scratchpad in 1984 and hadn't thought about it since :-)  .. but yes julia could use
some symbolic stuff

Stefan Karpinski

unread,
Mar 1, 2014, 6:32:55 PM3/1/14
to Julia Dev
On Sat, Mar 1, 2014 at 6:26 PM, Alan Edelman <mit.e...@gmail.com> wrote:
 
I still remember the days of Dick Jenks and scratchpad.

Was that your band in college? I would think there should be a "the" before "scratchpad".

Cristóvão Duarte Sousa

unread,
Mar 2, 2014, 6:31:01 PM3/2/14
to juli...@googlegroups.com
It is known that "There are those of [Julia main devs] who used Mathematica before we could grow facial hair", so, I guess a CAS in Julia was/is something desired from the beginning, although it has not happened yet.

So far I've found the following packages providing some kind of symbolic manipulation in Julia:

Right now I'm sticking with SymPy.jl (I think PyCall really is a big strength of Julia) and with my "not so carefully written" LinearExpressions.jl when enough.

I had already searched around to see if there was symbolic library in C which could be wrapped into Julia but the only one I found (I don't remember which was now) was not expressive enough to take advantage of Julia type system. CSymPy seems to be designed to be wrapped but it's C++ may be an issue. I also had superficially checked Axiom and thought it seems to have a very nice type system which may be replicable in Julia. Julia rich type system seems perfect to implement many types of symbolic expressions (linear expressions, uni and multivariate polynomials, general expressions) and symbolic variables (reals, matrices, ...), dispatched with its multiple-dispatch which could be complemented with one pattern matching package if needed. One thing I would personally enjoy in a hypothetical Julia CAS would be that it was primarily focused on efficiency (whatever that may mean) rather than featurefulness.

Let me finish linking to this StackOdesinigverflow thread which provided some resources on the design of CAS, being http://www.math.wpi.edu/IQP/BVCalcHist/calc5.html a very good reading.

Cheers,
Cristóvão

Cristóvão Duarte Sousa

unread,
Mar 3, 2014, 6:34:34 AM3/3/14
to juli...@googlegroups.com
Francesco Bonazzi, I've looked into https://github.com/daly/axiom/ but I haven't found the core mathematical objects you said. My knowledge of Lisp or SPAD/Aldor is zero. Can you please point me where the core type definitions are?


On Saturday, March 1, 2014 8:41:19 PM UTC, Francesco Bonazzi wrote:

Francesco Bonazzi

unread,
Mar 3, 2014, 4:28:44 PM3/3/14
to juli...@googlegroups.com

On Monday, March 3, 2014 12:34:34 PM UTC+1, Cristóvão Duarte Sousa wrote:
Francesco Bonazzi, I've looked into https://github.com/daly/axiom/ but I haven't found the core mathematical objects you said. My knowledge of Lisp or SPAD/Aldor is zero. Can you please point me where the core type definitions are?


Have a look here: https://github.com/hemmecke/open-axiom-svn/tree/master/src/algebra

The files .spad.pamphlet, are LaTeX-like files. Source code is contained inside a LaTeX block. It's a technique called literate programming (source code inside the documentation), so programmers are forced to write the documentation.

Francesco Bonazzi

unread,
Mar 3, 2014, 4:32:20 PM3/3/14
to juli...@googlegroups.com


On Monday, March 3, 2014 10:28:44 PM UTC+1, Francesco Bonazzi wrote:

On Monday, March 3, 2014 12:34:34 PM UTC+1, Cristóvão Duarte Sousa wrote:
Francesco Bonazzi, I've looked into https://github.com/daly/axiom/ but I haven't found the core mathematical objects you said. My knowledge of Lisp or SPAD/Aldor is zero. Can you please point me where the core type definitions are?



This looks to be a good tutorial about Aldor: http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/tutorial.pdf

Aldor is not exactly the same as SPAD, but it's almost equal.

The pamphlet files get separated as the first step of compilation.

If you install a compiled version of Axiom, you should be able to use that language from a terminal REPL.

Francesco Bonazzi

unread,
Mar 3, 2014, 4:54:08 PM3/3/14
to juli...@googlegroups.com


On Monday, March 3, 2014 12:31:01 AM UTC+1, Cristóvão Duarte Sousa wrote:

Yes, I would guess that over the time a lot more will appear, and maybe some of them would grow larger. The point is, if someone manages to translate Axiom into Julia, all those projects would not be necessary, as there would be a robust and powerful CAS library. I'm not 100% sure of its feasibility, but let's hope.

Right now I'm sticking with SymPy.jl (I think PyCall really is a big strength of Julia) and with my "not so carefully written" LinearExpressions.jl when enough.


The reason I didn't suggest to translate SymPy is that Python would probably require manual translation. There are classes and methods, which in Julia should be rewritten as external functions. Also, the lack of types definitions in functions/methods requires to analyze the code with a debugger, that's too much!

I discarded Maxima, because it is GPL licensed.

The fact that SPAD/Aldor is accidentally similar to Julia, makes it a lot easier to translate Axiom to Julia. The only issues that I found so far, are
  • SPAD/Axiom requires to declare the function return type. This information could just be thrown away after translating into Julia.
  • SPAD/Axiom has Categories, which are analogous abstract types, save for the possibility of defining which methods/operators have to be overridden by Domains (i.e. types) inheriting them. Again, this information could just be ignored, as it is the type inheriting the abstract which defines the methods (this mechanism is just a compiler check, I guess).

Fortunately this issues are a problem only when translating Julia to Aldor, not vice versa. I hope there are no issues that went undetected by my analysis.

In any case the design similarities between SPAD/Aldor and Julia are impressive, though the syntax is very different. Parametric types, default values to parameters in functions, macros, some kind of dispatch on functions, type system.

 
I had already searched around to see if there was symbolic library in C which could be wrapped into Julia but the only one I found (I don't remember which was now) was not expressive enough to take advantage of Julia type system. CSymPy seems to be designed to be wrapped but it's C++ may be an issue. I also had superficially checked Axiom and thought it seems to have a very nice type system which may be replicable in Julia. Julia rich type system seems perfect to implement many types of symbolic expressions (linear expressions, uni and multivariate polynomials, general expressions) and symbolic variables (reals, matrices, ...), dispatched with its multiple-dispatch which could be complemented with one pattern matching package if needed. One thing I would personally enjoy in a hypothetical Julia CAS would be that it was primarily focused on efficiency (whatever that may mean) rather than featurefulness.


CSymPy is just a clone of the core of SymPy, but it is just a beginning of a project. You cannot do integrals, solve equations and ODE with CSymPy.

Axiom has a robust and almost correct type system, possibly one of the best among all available CAS. By the way, it makes often use of parametric types (which SPAD/Aldor accidentally happen to possess, as in Julia). My idea is that Axiom was designed with efficiency in mind.

Konrad Hinsen

unread,
Mar 4, 2014, 2:54:06 AM3/4/14
to juli...@googlegroups.com
--On 3 mars 2014 13:54:08 -0800 Francesco Bonazzi <franz....@gmail.com>
wrote:

> Yes, I would guess that over the time a lot more will appear, and maybe
> some of them would grow larger. The point is, if someone manages to
> translate Axiom into Julia, all those projects would not be necessary, as
> there would be a robust and powerful CAS library. I'm not 100% sure of
> its feasibility, but let's hope.

The idea of a CAS library comes up regularly, which is why there are tons
of them. Unfortunately, few ever get developed to the point where they are
useful to a community big enough to ensure their survival.

Doing CAS right is a very difficult task. Anyone envisaging to start a new
CAS would do well to read some of Tim Daly's writings on the subject (it's
all on axiom-developer.org), where he refers repeatedly to the "30 year
horizon". The idea is that it's the mathematics behind CAS that's hard, not
the programming, so you need a stable and well-designed computational
platform that allows to make steady progress on the maths over the decades
it will inevitably take.

I suspect that the most promising approach to porting Axiom to the Julia
platform would be to write a translator from SPAD to Julia. Doing this by
hand is a huge task, likely to introduce errors, and there's always the
risk of discovering half-way through that you forgot about some important
aspect of SPAD that doesn't map to Julia in the way you thought. Writing a
SPAD->Julia compiler forces you to think everything through, and figure out
all the details of SPAD which is unfortunately badly documented.

Konrad.

Cristóvão Duarte Sousa

unread,
Mar 4, 2014, 4:41:27 AM3/4/14
to juli...@googlegroups.com
Thanks Francesco for the links. Looking inside the the source code, from a language ignorant point of view, the task of translating it into Julia seems to require a herculean effort, either doing that manually or by creating a translation tool...

Konrad, personally I like to think in a Julia CAS as something more like what SymPy is to Python or Symbolic Toolbox is to MATLAB rather than a full CAS like Axiom or Mathematica. Having something, even if far from perfect, is better than having nothing. Anyway, the structure of Julia is probably more suitable for a CAS than many other languages. 

About translating Axiom to Julia, I would say the first step is to try a manual translating of some core parts like data structures and basic algebra.

Konrad Hinsen

unread,
Mar 4, 2014, 11:59:22 AM3/4/14
to juli...@googlegroups.com
Cristóvão Duarte Sousa writes:

> Konrad, personally I like to think in a Julia CAS as something more
> like what SymPy is to Python or Symbolic Toolbox is to MATLAB
> rather than a full CAS like Axiom or Mathematica.

That's fine, but I wouldn't call it a CAS. Nor would I call SymPy a CAS.
But that's of course a matter of definition.

In any case, it's worth defining the goal of such a project before
discussing the technicalities.

> Anyway, the structure of Julia is probably more suitable for a CAS
> than many other languages.

Better than Lisp? I have doubts about that. Lisp is hard to beat for
symbolic computation in a general-purpose language.

Julia's strong point is numerics. I'd see the main reason for adding
symbolic computation in doing mixed symbolic-numeric computations.
Just as for Python and SymPy.

> About translating Axiom to Julia, I would say the first step is to
> try a manual translating of some core parts like data structures
> and basic algebra.

That sounds like translating most of the Lisp code in Axiom - not
a trivial task.

Konrad.

Cristóvão Duarte Sousa

unread,
Mar 4, 2014, 12:43:59 PM3/4/14
to juli...@googlegroups.com
Well, maybe I have been abusing the CAS definition. Due to Julia primary goals it would probably never be a full CAS, and for sure not a "Julia is a CAS", however, as you said, it can be good for mixed symbolic-numeric computations.
By the way, SymPy seems to at least be aiming to "become a full-featured CAS"[http://sympy.org/en/index.html].

About the "goal of such a project", from my part this has been more like wishful thinking that anything else...
I hope that by maintaining the discussion alive, someone with the proper knowledge, will and time starts a symbolics Julia project.
In that case I'll be happy whatever the goals are, and I'll try to contribute where I can.

Theodore Papamarkou

unread,
Mar 4, 2014, 4:22:20 PM3/4/14
to juli...@googlegroups.com
I would give anything for a free weekly "pass" to Mathematica's symbolic source code. Given that this is not possible, I would suggest reading Joel Moses "Macsyma: A Personal History" (2008). This may inspire you to read the Lisp-based source code of the Maxima descedant and then reproduce it in Julia. I want to do this but maybe in another life due to lack of time.

Simon Byrne

unread,
Mar 5, 2014, 4:54:03 AM3/5/14
to juli...@googlegroups.com
On a related note, I have been working on an interface to Mathematica from Julia. At the moment, this consists of just a wrapper to the MathLink library that is used by Mathematica for communicating with external programs:

The library works by `mlput`-ing a sequence of tokens (functions, symbols, numbers or strings) that are used to build up a mathematica expression. Then you `mlget` the sequence of return values.

The next step is to build a more convenient interface for all this, however I'm not sure what is the best way to proceed. I would be keen to hear of any suggestions others might have.

Simon

Theodore Papamarkou

unread,
Mar 5, 2014, 5:26:33 AM3/5/14
to juli...@googlegroups.com
This upcoming MathLink package is a very helpful contribution. I was thinking of two potential (and possibly orthogonal) approaches to create the interface. One approach, which I think is aligned with the work you have done so far, is to rely on the MathLink API first and then to wrap-hie these MathLink function calls using some higher-level Julia functions (that will be dealing with activation etc). Then the user won't have to worry about directly calling any of the functions in this link:


A second approach would be to create a composition of two mappings (each of them being one-to-one) between Julia<->C<->Mathematica for arrays, lists, expressions. Then a Julia expression will be internally represented by a Mathematica object which 
would be handled by the MathLink API. Here is the link that made me think of this approach:


I am not entirely sure which approach is more realistic as I haven't played around with your code, neither I have read through the MathLink API documentation so my thoughts may not be very useful. Thanks for working on the Julia MathLink API.

David de Laat

unread,
Mar 5, 2014, 5:35:18 AM3/5/14
to juli...@googlegroups.com
See also this package by Mike Innes:
https://github.com/one-more-minute/Mathematica.jl

Simon Byrne

unread,
Mar 5, 2014, 6:00:20 AM3/5/14
to juli...@googlegroups.com
On Wednesday, 5 March 2014 10:35:18 UTC, David de Laat wrote:
See also this package by Mike Innes:
https://github.com/one-more-minute/Mathematica.jl

Thanks! I wasn't aware of that, it looks like it has lots of good ideas.

On Wed, Mar 5, 2014 at 11:26 AM, Theodore Papamarkou <theodore....@gmail.com> wrote:
>
> This upcoming MathLink package is a very helpful contribution. I was thinking of two potential (and possibly orthogonal) approaches to create the interface. One approach, which I think is aligned with the work you have done so far, is to rely on the MathLink API first and then to wrap-hie these MathLink function calls using some higher-level Julia functions (that will be dealing with activation etc). Then the user won't have to worry about directly calling any of the functions in this link:
>
> http://reference.wolfram.com/mathematica/tutorial/RunningMathematicaFromWithinAnExternalProgram.html

This would seem the easiest option, the problem is how we handle expressions: i.e. how do we stop the sin being evaluated in 
integrate(cos(x),x)
There's probably some room for some macro trickery here, i.e. we could do something like
@matheval integrate(cos(x),x)
which could then return an Expr object :(sin(x)) 

> A second approach would be to create a composition of two mappings (each of them being one-to-one) between Julia<->C<->Mathematica for arrays, lists, expressions. Then a Julia expression will be internally represented by a Mathematica object which
> would be handled by the MathLink API. Here is the link that made me think of this approach:
>
> http://reference.wolfram.com/mathematica/tutorial/HandlingListsArraysAndOtherExpressions.html

That seems closer in spirit to the PyCall.jl inteface: however the problem is that we can't access the mathematica objects directly, we can see what is returned from a function evaluation. It might be possible to imitate this somehow though.

Simon Byrne

unread,
Mar 5, 2014, 6:01:42 AM3/5/14
to juli...@googlegroups.com
On Wednesday, 5 March 2014 11:00:20 UTC, Simon Byrne wrote:
i.e. how do we stop the sin being evaluated in 

that should be cos, not sin.

Theodore Papamarkou

unread,
Mar 5, 2014, 6:24:32 AM3/5/14
to juli...@googlegroups.com
I didn't think that we can't access the Mathematica objects directly, you are right (this makes the second approach a bit less likely). Yes, the first approach seems almost certainly plausible, a bit of metaprogramming will probably provide a workaround for the cos evaluation.

As for the Mathematica.jl package, I didn't know it either, I will start playing around both with MathLink.jl and Mathematica.jl

Ivar Nesje

unread,
Mar 5, 2014, 9:45:59 AM3/5/14
to juli...@googlegroups.com
Julia supports two very convenient syntaxes for getting the expression tree, instead of the evaluation into a "function"

* Make the function a macro (eg @integrate(sin(x), x, 0, 2pi))

* Require the user to quote the expression (eg. integrate(:(sin(x)), :x, 0, 2pi))

The function interface is easier to get right, and I would start by providing that.

Ivar

Francesco Bonazzi

unread,
Mar 5, 2014, 12:32:23 PM3/5/14
to juli...@googlegroups.com


On Wednesday, March 5, 2014 3:45:59 PM UTC+1, Ivar Nesje wrote:
Julia supports two very convenient syntaxes for getting the expression tree, instead of the evaluation into a "function"

* Make the function a macro (eg @integrate(sin(x), x, 0, 2pi))

* Require the user to quote the expression (eg. integrate(:(sin(x)), :x, 0, 2pi))

The function interface is easier to get right, and I would start by providing that.


That is the logic of macros and held expressions, which were inherited from Lisp.

Mathematica allows to use unassigned variables as math symbols by default, without any need of macros or :( ... ) operators.

In any case, I would still prefer to use types and assignments. Example of a hypothetical symbolic math module:

julia> x = MathSymbol('x')
julia
> integrate(x^2, x)
x
^3/3

One could also hypothetically implement Ito calculus, and have something like

julia> w = BrownianMotion('w')
julia
> integrate(w^2, w)
... resulting stochastic process ...

The same would apply on many other fields, choosing the algorithm by the type of parameters.

I don't see this as an issue. SymPy has a similar approach, they also provide an IPython profile with the ability to automatically detect all unknown variables, declaring them as base symbols. A similar approach could be thought on top of IJulia.

Mike Innes

unread,
Mar 5, 2014, 4:14:10 PM3/5/14
to juli...@googlegroups.com
Hi Simon - Mathematica.jl author here. Unless you're planning on heading in a radically different direction with the high-level interface, it would be great if we could pull our efforts together. I'd be interested to look through your code, at any rate, so I will when I have some time. You can give Mathematica.jl a go with Pkg.clone("Mathematica").

This would seem the easiest option, the problem is how we handle expressions: i.e. how do we stop the sin being evaluated in 
integrate(cos(x),x)

Mathematica.jl handles this by exposing Mathematica's semantics as far as possible. So Sin(0.5) returns 0.48, but Sin(:x) return the same Mathematica expression unevaluated. You can therefore call Integrate(Sin(:x), :x)and it will return :(*(-1,Cos(x))) as expected. You can also use the macro version and the built-in aliases to make this look a bit more natural, e.g. @Integrate(2y*log(x), x). It's easy to add your own data types and aliases, too. Let me know what you think, or if you have any suggestions, of course.

Cheers!

Simon Byrne

unread,
Mar 6, 2014, 5:48:57 AM3/6/14
to juli...@googlegroups.com
I agree we should pool our efforts. I've had a quick look at the implementation and it looks very impressive (I see you have some experience in wrapping Mathematica). I'll play around with it some more and see where I get to.

Francesco Bonazzi

unread,
Mar 7, 2014, 3:19:21 AM3/7/14
to juli...@googlegroups.com
It's curious that I started this thread with the intent of launching a BSD-licensed symbolic math package in Julia. I excluded Maxima because I felt that GPL license was too restrictive, and the discussion ended up with plans to call Mathematica from Julia, which is a paid proprietary software. That's just a curious topic evolution :)

I know that Mathematica would be thousands times better then Axiom, but people need to pay for it.

Theodore Papamarkou

unread,
Mar 7, 2014, 3:24:23 AM3/7/14
to juli...@googlegroups.com
I may be wrong about this but my impression is that the GPL license does not necessarily prohibit us learning from it to create a Julia symbolic toolbox. We can always contact the Maxima developers and ask for their permission after all, if the only consideration against Maxima is its license.

Francesco Bonazzi

unread,
Mar 7, 2014, 4:04:52 AM3/7/14
to juli...@googlegroups.com


On Friday, March 7, 2014 9:24:23 AM UTC+1, Theodore Papamarkou wrote:
I may be wrong about this but my impression is that the GPL license does not necessarily prohibit us learning from it to create a Julia symbolic toolbox.

That's right, it is possible to read the code, get the idea on how to write it, and write something similar under another license.
 
We can always contact the Maxima developers and ask for their permission after all,

According to Wikipedia:

In 1998, Schelter obtained permission from the Department of Energy to release his version under the GPL. That version, now called Maxima, is maintained by an independent group of users and developers.

My interpretation of this text is that the copyright holder is still the Department of Energy.
 
 
if the only consideration against Maxima is its license.

I am currently examining Axiom's source code, and it turns out that the logic upon which was built the SPAD/Aldor programming language is very close to Julia's one. I think that a SPAD-to-Julia compiler would not be a difficult task to achieve, I am currently studying its feasibility.

I don't know much about Common Lisp used by Maxima. By the way, does Maxima use types/multiple dispatching or metaprogramming?

Personally, I think that marking symbols by their types is good (Mathematica does not do that).

Have a look at this: http://www.cs.ru.nl/E.Poll/talks/axiom.pdf

An Axiom-based CAS would be an attempt to do both symbolic math and mathematical logic. By the way, with a precise type systems, it is also possible to take advantage of Julia's multiple dispatch mechanism.

Theodore Papamarkou

unread,
Mar 7, 2014, 4:14:07 AM3/7/14
to juli...@googlegroups.com
You are probably right about GPL, I now remember that I have seen this remark elsewhere in the Julia forums.

I haven't used Axiom. I am partly sold already, due to slide 15 of the pdf you sent me, it seems that their categorical hierarchy is carefully designed. A few questions (due to lack of knowledge about Axiom):
1. How easy is to map the Axiom types to Julia types?
2. Is the type hierarchy in Axiom easily emulated in Julia?
3. Are there active Axiom developers or community (since questions may arise)?
4. Above all, how good is Axiom for doing computer algebra (compared to Mathematica for ex)?

Theodore Papamarkou

unread,
Mar 7, 2014, 4:15:22 AM3/7/14
to juli...@googlegroups.com
P.S. A mistake above, in point 2, I meant the Axiom type inheritance.

Cristóvão Duarte Sousa

unread,
Mar 7, 2014, 4:15:03 AM3/7/14
to juli...@googlegroups.com
Juging by https://www.ma.utexas.edu/pipermail/maxima/2013/032006.html it seems Axiom is one genereation ahead of Maxima.

Simon Byrne

unread,
Mar 7, 2014, 5:27:15 AM3/7/14
to juli...@googlegroups.com
On Friday, 7 March 2014 08:19:21 UTC, Francesco Bonazzi wrote:
It's curious that I started this thread with the intent of launching a BSD-licensed symbolic math package in Julia. I excluded Maxima because I felt that GPL license was too restrictive, and the discussion ended up with plans to call Mathematica from Julia, which is a paid proprietary software. That's just a curious topic evolution :)

Yes, I fully acknowledge the irony here. However given the wide variety of options, perhaps it would be worthwhile to think about a common interface to symbolic operations, which could then be farmed out to the backend of choice (mathematica, sympy, axiom, maxima, etc.), in a similar manner to the JuMP package?


Cristóvão Duarte Sousa

unread,
Mar 7, 2014, 10:37:46 AM3/7/14
to juli...@googlegroups.com
I've noticed that Axiom allows some kind of pattern matching as in
> fib(0) == 0
> fib(1) == 1
> fib(n) == fib(n-2) + fib(n-1)
> fib(6)
8
I wonder, is this standard SPAD/Aldor language, or is it just a higher level feature of Axiom command line interface?

On Saturday, March 1, 2014 8:41:19 PM UTC, Francesco Bonazzi wrote:
I have read of discussion of implementations of Computer Algebra Systems on this discussion in the past. I would like to propose a solution which avoids having to reason with the logic of mathematical algorithms.

Axiom is a FOSS computer algebra system, started in 1971, released under the New BSD license in 2001. Since 2007 it has been forked into two projects: FriCAS and Open-Axiom.

http://en.wikipedia.org/wiki/Axiom_%28computer_algebra_system%29

Axiom is written in its own programming language, called SPAD. It is both object-oriented and functional, probably inspired by Lisp. SPAD has been the basis for Aldor, its direct heir, which has more documentation available on the internet (SPAD and Aldor are very similar in their syntax). Technically, Axiom is written in literate programming (LaTeX with code blobs), it is therefore well-documented.

I had a look at Axiom's source code, I think that SPAD has many logical similarities with Julia. Axiom defines mathematical objects (monoids, rings, fields, etc...), functions in SPAD support type-overloading and parametric types (these ones are extensively used). Object methods are defined in a way similar to Julia, even operator overloading supports both forms +(a, b) and a+b.

A possible concern may be SPAD's domains and categories. Roughly speaking, domain is similar to Julia's types with operators overloaded, while categories are abstract types. Unlike Julia, SPAD categories define the methods that domains inheriting them have to implement, so categories look like Java's interfaces or abstract classes.

http://en.wikipedia.org/wiki/Aldor

(by the way, I am wondering whether some of Julia's developers got inspired by Aldor, or whether it is just a coincidence).

The advantages of translating Axiom into Julia are primarily:
  • Julia would have its own Computer Algebra System as a package (example of usage: enable some kinds of symbolic optimization).
  • Axiom has currently few people developing it, due to the steep learning curve of the SPAD programming language (it has very little documentation on the internet, and it is used only in Axiom). Translating Axiom to a more common language would probably boost its development rate, as new developers would find it easier to contribute.
  • Both FriCAS and Open-Axiom are developed on Sourceforge, github would be a more comfortable website.

Maybe a collection of regex could be sufficient to translate Axiom's code (save for possible complications).

Axiom has many mature algorithms, it can symbolically differentiate, integrate, solve ODEs, solve equations and so on. It is still not as powerful as Mathematica.

Francesco Bonazzi

unread,
Mar 7, 2014, 1:27:34 PM3/7/14
to juli...@googlegroups.com


On Friday, March 7, 2014 11:27:15 AM UTC+1, Simon Byrne wrote:
 However given the wide variety of options, perhaps it would be worthwhile to think about a common interface to symbolic operations, which could then be farmed out to the backend of choice (mathematica, sympy, axiom, maxima, etc.), in a similar manner to the JuMP package?

Sounds a bit like a Julia version of Sage :)

Iain Dunning

unread,
Mar 7, 2014, 8:55:17 PM3/7/14
to juli...@googlegroups.com
I keep seeing JuMP mentioned in this long thread, and just want to jump in briefly. JuMP is probably one of Julia packages that makes the most use of "symbolic math" right now, but its not really anything like the things you are talking about or comparing it to. JuMP is a modeling tool that allows for easy translation of the natural statements of optimizations into code, then takes that code and efficiently generates the data structures required by solvers. We achieve this both by acting directly on the Julia AST (e.g. @addConstraint) and by using operator overloading as a fallback. Speed of transformation between the model representation and the representation required by the solvers is a top priority for us, and we'd be unlikely to use/need a more general CAS.

As a tip, it seems to me that you are making things more complicated than they need to be. Packages than can symbolically differentiate equations have existed in Julia a long time (e.g. Calculus.jl), and it seems to me that getting most of the things you want from theses CASs are simply a matter of figuring out/copying the existing algorithms and applying them to Julia ASTs. You can get the chain rule working in about 10 minutes, and I can't imagine that integration is that much worse if you've got a BSD/MIT/GLP licensed body of code to refer back to. The "common backend" for all these operations could just be the AST, maybe slightly wrapped if it would help. I don't want to opine any further though because I'm at the limits of my knowledge in this area.

Cheers,
Iain

Jason Merrill

unread,
Mar 7, 2014, 9:19:18 PM3/7/14
to juli...@googlegroups.com
On Friday, March 7, 2014 5:55:17 PM UTC-8, Iain Dunning wrote:
As a tip, it seems to me that you are making things more complicated than they need to be. Packages than can symbolically differentiate equations have existed in Julia a long time (e.g. Calculus.jl), and it seems to me that getting most of the things you want from theses CASs are simply a matter of figuring out/copying the existing algorithms and applying them to Julia ASTs. You can get the chain rule working in about 10 minutes, and I can't imagine that integration is that much worse if you've got a BSD/MIT/GLP licensed body of code to refer back to. The "common backend" for all these operations could just be the AST, maybe slightly wrapped if it would help. I don't want to opine any further though because I'm at the limits of my knowledge in this area.

Integration is a lot harder than differentiation. Unfortunately, there isn't a chain rule for integration that lets you express the integral of a composition of functions in terms of the integral of the functions. According to http://reference.wolfram.com/mathematica/tutorial/SomeNotesOnInternalImplementation.html#481 the code for Mathematica's Integrate is 500 pages of Mathematica and 600 pages of C.

Have a look at Sympy's integrate folder if you're interested in an open implementation of some of the techniques people use:

https://github.com/sympy/sympy/tree/master/sympy/integrals

--Jason
 
Cheers,
Iain

Stefan Karpinski

unread,
Mar 7, 2014, 9:37:22 PM3/7/14
to juli...@googlegroups.com
"Pages" seems like a really unintuitive measure of code. How big is the font and the page? How much is that in lines of code?

Francesco Bonazzi

unread,
Mar 8, 2014, 4:36:08 AM3/8/14
to juli...@googlegroups.com


On Friday, March 7, 2014 10:14:07 AM UTC+1, Theodore Papamarkou wrote:
I haven't used Axiom. I am partly sold already, due to slide 15 of the pdf you sent me, it seems that their categorical hierarchy is carefully designed. A few questions (due to lack of knowledge about Axiom):
1. How easy is to map the Axiom types to Julia types?

Hard. Axiom has domains and categories.

Categories are abstract types, which define virtual methods on them, without specifying any source code for those methods.

Domains inheriting a category implement all of the category methods, plus possible additional methods. Method implementation is checked at compile time.
 
2. Is the type hierarchy in Axiom easily emulated in Julia?

The type hierarchy in Axiom is performed in a very strange way. There is a has operator which looks if a domain is part of a category (domain has category ===> true/false). Unfortunately this is not an inheritance check, this just checks which methods are implemented by the domain, and verifies that all of them also appear in the category.

This means, a domain has a category even if it didn't inherit that category when it was declared. This has advantages in abstract math: developers don't have to care about type inheritance, they just need to overload the operators necessary to represent the algebraic structure relation. Inheritance is dynamically inferred by SPAD/Aldor.

I still don't have an idea on how to do this efficiently in Julia. Furthermore, methods are checked based also on their return type, which Julia does not declare.

3. Are there active Axiom developers or community (since questions may arise)?

Yes, Axiom has been forked into OpenAxiom and FriCAS, both of which are under active development.
 
4. Above all, how good is Axiom for doing computer algebra (compared to Mathematica for ex)?

Obviously Mathematica is the best currently available CAS, so all other ones are usually less good than it.

Considering that Sage is linked to Maxima, and not to Axiom, I believe Maxima is better than Axiom. As previously mentioned, the strong point of Axiom is the type system, which other CAS lack. I blame the slow development of Axiom to the fact that learning SPAD/Aldor causes a steep learning curve for people willing to join the project, and the communities remain small. Furthermore now Axiom has been forked into two communities.

My belief is that Axiom would greatly benefit in terms of developing community if it is rewritten into an easier programming language.
Message has been deleted

Theodore Papamarkou

unread,
Mar 8, 2014, 4:59:23 AM3/8/14
to juli...@googlegroups.com
Oups, sorry, sth went wrong with my message and had to repost. Thanks for the detailed reply Francesco. Let me tell you first of all that I am very pleased that you have an interest in developing a CAS in Julia. This is partly due to my general interest in abstract algebra, computer algebra and symbolic computations and more recently in iterated integrals involved in rough differential equations that do require substantial symbolic computations.

About point 1, my hope is that Julia's multiple dispatch may help to map the Axiom categories and domains to Julia types. In some abstract sense, multiple dispatch is a way of using OO virtual methods. My understanding is that the main difficulty of Axiom's strong type system is that it requires a fair amount of mathematical knowledge related to rings, various types of groups, and other notions from abstract algebra, so not everyone can start developing code that way without doing some reading first.

About point 2, it worries me a bit because of the lack of type inheritance in Julia, but it is likely that this can be emulated with careful design of types.

About point 3, good to hear that there are active Axiom developers.

Finally about 4, my main point is how well Axiom compares to other CAS. Mathematica is the gold standard, but more generally the question is how good you consider Axiom to be (from a user's point of view) in comparison to SymPy, Maxima etc.

It sounds you are experienced with Axiom. What is your favourite tutorial or user guide for it? If you provide me with some documentation, I will try to find some time to play around with it.

Mike Innes

unread,
Mar 8, 2014, 5:04:40 AM3/8/14
to juli...@googlegroups.com
The type hierarchy in Axiom is performed in a very strange way. There is a has operator which looks if a domain is part of a category (domain has category ===> true/false). Unfortunately this is not an inheritance check, this just checks which methods are implemented by the domain, and verifies that all of them also appear in the category.

Like Go interfaces? Funnily enough, I was thinking of implementing something just like this a while back. You could do something like

@category type ArrayLike
  getindex(_, Any)
  length(_) 
  ...
end

Then you can use @implements ArrayLike [1,2,3], which would use methodexists() under the covers (caching the result for performance). That way implementing new array types is easier, since you can check which functions need to be implemented, and you can have some sort of static typing in generic code without restricting it to one branch of the type hierarchy. You could also use return type checking, potentially, but that would need more advanced code analysis, like that in TypeCheck.jl perhaps.

Does Axiom dispatch on categories? If so, this approach probably won't work, but otherwise it could be helpful.

I'm interested in this project, anyway, so I think I'll add it to the GSoC page if I get a chance.

Cristóvão Duarte Sousa

unread,
Mar 8, 2014, 11:01:26 AM3/8/14
to juli...@googlegroups.com
About using Julia AST to represent symbolic expressions, I think the problem is that the variables (symbols) and expressions have no "mathematical type" information attached to them. That would lose the great advantage of Julia multiple dispatch (indeed, I've seen some people wondering why Julia Expr doesn't take that advantage of it in the first place). One could keep and pass around an object of "type context" or "assumptions" but that would just feel like an unnecessary workaround in Julia.

As it says in Wikipedia, Axiom has a "mathematically (mostly) correct type hierarchy", which would be really really great if it were implementable in Julia in a straightforward way. On the other hand, wanting to have "all" Axiom in Julia may be "making things more complicated than they need to be".

I've been reading the first pages of "Axiom Jenks and Sutor—The main textbook" and I can say it's worth it.
Two quotes from pages 5 and 6, about Axiom interactive programming:

    "By compiled, we mean that the function is translated into basic machine-code."
    "In general, a user function is type-analyzed and compiled on first use. Later, if you use it
     with a di erent kind of object, the function is recompiled if necessary."

Does this not sound familiar? :)

Kevin Squire

unread,
Mar 8, 2014, 6:25:53 PM3/8/14
to juli...@googlegroups.com
Check out the interface implementation in Graphs.jl (http://julialang.org/Graphs.jl/interface.html#interface-declaration-and-verification).  I haven't studied it carefully, so I don't know how well it matches up with Go interfaces or your proposal, but it seems to have had a similar inspiration.

Kevin

Mike Innes

unread,
Mar 9, 2014, 10:31:50 AM3/9/14
to juli...@googlegroups.com
Kevin: Interesting - it's a little different in that you have to explicitly register types as belonging to an interface, but it could definitely be something to build on.

FYI, a "port of Axiom" project is now on the GSoC page - http://julialang.org/gsoc/2014/. Francesco, you're clearly much more knowledgeable about this than I am, so if you want to make any changes to the project description please go ahead.

Francesco Bonazzi

unread,
Mar 10, 2014, 5:59:21 PM3/10/14
to juli...@googlegroups.com
First of all, I am no expert in Aldor. I would never use that language, nor would I suggest anyone to learn it. What matters is Axiom's source code and the information it contains.


On Sunday, March 9, 2014 3:31:50 PM UTC+1, Mike Innes wrote:
FYI, a "port of Axiom" project is now on the GSoC page - http://julialang.org/gsoc/2014/. Francesco, you're clearly much more knowledgeable about this than I am, so if you want to make any changes to the project description please go ahead.


OK, but I'm not very sure how easy it is to port Axiom to Julia. The Aldor parser itself is a hard task, but we don't need to create a correct parser, we just need to extract the information encoded in Axiom's source code, and that's all.

Furthermore, in SPAD/Aldor, function access, parametric types and list getindex have the same syntax. This requires some degree of type inference to choose between { }, ( ), and [ ] when translating to Julia.

In any case, SPAD/Aldor was a great language in the 70s/80s, but I don't see much future now for it, its syntax is just horrible and unintuitive. OTOH, I like some features of Aldor, and I think it would be great to have them in Julia too.

Is it possible to have a wiki page to put a table of SPAD-to-Julia translation samples? (this can be a good strart to gather examples of SPAD-to-Julia translation).

The latest version of Open Axiom has 229 categories and 864 domains. I don't know exactly whether interfaces are good to represent these ones in Julia. I'll do some tests in the next weeks. Axiom's types remain a major challenge.

Theodore Papamarkou

unread,
Mar 11, 2014, 5:47:01 AM3/11/14
to juli...@googlegroups.com
If I am not wrong, all the computer algebra attempts in Julia so far have revolved around the idea of using Julia expressions for doing symbolic computations. This is an approach compatible with systems such as Maxima. However, if we want to move on to a strongly and mathematically typed system such as Axiom, then obviously we can not use expressions as the sole building block for doing symbolic computations. We certainly need a very carefully crafted type system that emulates the principles of Axiom (not Axiom itself necessarily). So apparently the starting point, if we are going down that road, is to design and code this type hierarchy as a whole before defining any multiply dispatched functions operating on these types, otherwise we will hinder development in the future. If we all agree that the question is how we can translate the Axiom type system to a Julia typed framework for symbolic computation and that type inheritance is the main possible challenge, then we have a very concrete question to answer. I don't know the answer to this question, but at least I think that the rising question and direction is obvious.

Francesco Bonazzi

unread,
Mar 14, 2014, 12:57:51 PM3/14/14
to juli...@googlegroups.com
UPDATE:

I just found out that the aldor compiler has a very interesting output format, obtained with -Fap arguments.

Consider this test file, let's say test.as:

#include "aldor"

fib
(n: Integer): Integer == {
        n
< 0 => 0;
        n
< 3 => 1;
        fib
(n-1) + fib(n-2);
}

Aldor's compilation outputs are: executable, Lisp, C, C++ and AP (parsed aldor).

Lisp and C outputs are horrible, but look at the AP format output:

(Sequence
 
(Sequence () ())
 
(Import () AldorLib)
 
(Inline () AldorLib)
 
()
 
(Import () Boolean)
 
(Sequence () ())
 
()
 
()
 
(Define
   
(Declare fib (Apply -> (Declare n AldorInteger) AldorInteger))
   
(Lambda
     
(Comma (Declare n AldorInteger))
     
AldorInteger
     
(Label
        fib
       
(Sequence
         
(Exit (Test (Apply < n \0)) \0)
         
(Exit (Test (Apply < n (LitInteger "3"))) \1)
         
(Apply
           
+
           
(Apply fib (Apply - n \1))
           
(Apply fib (Apply - n (LitInteger "2")))))))))

This looks to me like a Lisp-like metasyntax which is very easy to parse and translate to Julia.

I did further research, it looks like FriCAS, one of Axiom's two forks, can be compiled with Aldor (instead of SPAD). This is definitely the best solution I found so far.

Stefan Karpinski

unread,
Mar 14, 2014, 6:04:47 PM3/14/14
to Julia Dev
That does look fairly promising as something one could translate to Julia AST and then pretty print back to source. Of course, the Julia AST pretty printing probably needs some work, but I suspect that's the easiest approach.

Ralf Hemmecke

unread,
Mar 16, 2014, 7:01:37 PM3/16/14
to juli...@googlegroups.com
I don't know much about Julia, but I know Aldor.
I've just browsed through the language description of Julia.
To me it looks hard, if not in general impossible to translate Aldor (or SPAD) into Julia.
But I've seen that Julia can call C code or being called from C. The same applies to Aldor (not to SPAD).
So it would be an option to call the Aldor library code from Julia.

Now, the Aldor library has quite some symbolic stuff, but it is by far not as rich as the library that FriCAS builds on.
Unfortunately, due to the way FriCAS is built, it's not trivial to move the whole FriCAS library into Aldor. (Quite a lot of work anyway.)

Just an idea how one could add at least some symbolic routines to Julia.

Ralf

Bill Page

unread,
Mar 17, 2014, 1:38:11 PM3/17/14
to juli...@googlegroups.com


On Monday, 3 March 2014 16:54:08 UTC-5, Francesco Bonazzi wrote:
...
The fact that SPAD/Aldor is accidentally similar to Julia, makes it a lot easier to translate Axiom to Julia. The only issues that I found so far, are
  • SPAD/Axiom requires to declare the function return type. This information could just be thrown away after translating into Julia.
  • SPAD/Axiom has Categories, which are analogous abstract types, save for the possibility of defining which methods/operators have to be overridden by Domains (i.e. types) inheriting them. Again, this information could just be ignored, as it is the type inheriting the abstract which defines the methods (this mechanism is just a compiler check, I guess).

Fortunately this issues are a problem only when translating Julia to Aldor, not vice versa. I hope there are no issues that went undetected by my analysis.

Function overloading in SPAD (called multiple dispatch in Julia) depends not only on the function arguments but also the return type of the function, although dispatch involving function return type is probably used only infrequently in the FriCAS library.

An aside: I dislike the notion of a function without a statically defined return type.  I have a similar issue with SPAD and Aldor since although the return type is well-defined it can never the less be dependent on parameter values.  I think such flexibility is not a good thing in a language that already has such an expressive type system. In language design there is such a thing as being too generous. I would prefer instead that all functions to be instances of higher-order "mapping" types so that together with products (tuples) and unions the type system would have the simple semantics of a closed monoidal category ( http://en.wikipedia.org/wiki/Closed_monoidal_category ). But that is another story.

Also I think you should not dismiss so quickly the importance of Categories in SPAD. (Note: Although there are some significant analogies, Categories in SPAD should not be confused with the concept of category in mathematics.). In particular Categories provide an important and frequently used mechanism for generic programming in the FriCAS library. Besides defining a "methods contract" for all domains belonging to a Category, Categories often define default implementations of functions (methods) that considerably simplify the coding new domains.  In effect Categories are where the "axioms" are implemented in the Axiom system and it's derivatives (FriCAS, OpenAxiom and Aldor).
 

In any case the design similarities between SPAD/Aldor and Julia are impressive, though the syntax is very different. Parametric types, default values to parameters in functions, macros, some kind of dispatch on functions, type system.

Yes.
 

...

Axiom has a robust and almost correct type system, possibly one of the best among all available CAS. By the way, it makes often use of parametric types (which SPAD/Aldor accidentally happen to possess, as in Julia). My idea is that Axiom was designed with efficiency in mind.

I think most devotees of Axiom would claim that it was Axiom that actually invented the concept.  In fact being originally designed in the early 1980's Axiom pre-dated almost all of what later became known as object-oriented languages. 

Cheers,
Bill Page.

Francesco Bonazzi

unread,
Mar 19, 2014, 7:36:06 AM3/19/14
to juli...@googlegroups.com


On Monday, March 17, 2014 12:01:37 AM UTC+1, Ralf Hemmecke wrote:
I don't know much about Julia, but I know Aldor.
I've just browsed through the language description of Julia.
To me it looks hard, if not in general impossible to translate Aldor (or SPAD) into Julia.

The strong point of Julia are macros, they are very powerful and could allow the emulation of type systems of other programming languages. Of course I know it would be better to avoid macros as much as possible and try to use native Julia constructs instead, but I fear they will be needed.

To me, parsing SPAD code is a harder task. But the SPAD compiler can drop the parsed AST at various compilation level, as it has been pointed out on the FriCAS forum. That is a kind of blessing to know.

But I've seen that Julia can call C code or being called from C. The same applies to Aldor (not to SPAD).
So it would be an option to call the Aldor library code from Julia.

Yes, Julia can also call Python and Java code. I'm no expert of this, but once Julia's C API will be fully documented, this will be easy. In any case, there is already SymPy.jl to call SymPy from Julia.
 

Just an idea how one could add at least some symbolic routines to Julia.


That looks like building a fork of Sage inside Julia. That would be an interesting project, too, i.e. not implementing any math at all, and have calls to external libraries. Due to Julia's package system, this could solve a lot of Sage's portability issues.

Francesco Bonazzi

unread,
Mar 19, 2014, 7:52:17 AM3/19/14
to juli...@googlegroups.com


On Monday, March 17, 2014 6:38:11 PM UTC+1, Bill Page wrote:

Function overloading in SPAD (called multiple dispatch in Julia) depends not only on the function arguments but also the return type of the function, although dispatch involving function return type is probably used only infrequently in the FriCAS library.

Yes. I also noticed that functions themselves are dispatched according to their argument types, while in Julia a function object is just a Function type. I believe the idea behind Julia's function is to be simple. The return type of a function actually exists, and it is inferred at compile time as the smallest supertype of all returned variable types (correct me if I'm wrong).

I believe that symbolic mathematical functions should be represented as objects, not as functions. I wonder if there is any idea on making objects callable, like the __call__(self, *args) of Python, which is used in SymPy's Function objects.
 
An aside: I dislike the notion of a function without a statically defined return type.  I have a similar issue with SPAD and Aldor since although the return type is well-defined it can never the less be dependent on parameter values.  I think such flexibility is not a good thing in a language that already has such an expressive type system. In language design there is such a thing as being too generous.

This issue could be addressed by code analysis in an IDE.

 
Also I think you should not dismiss so quickly the importance of Categories in SPAD. (Note: Although there are some significant analogies, Categories in SPAD should not be confused with the concept of category in mathematics.). In particular Categories provide an important and frequently used mechanism for generic programming in the FriCAS library. Besides defining a "methods contract" for all domains belonging to a Category, Categories often define default implementations of functions (methods) that considerably simplify the coding new domains.  In effect Categories are where the "axioms" are implemented in the Axiom system and it's derivatives (FriCAS, OpenAxiom and Aldor).
 

Categories look somewhat like traits in Scala, or interfaces in the new Java 8, except that they are the types of domains. I'm currently pondering about how to emulate them in Julia.

Domain inheritance is also a problem, as only abstract types can be inherited in Julia. Again, this can be solved by a type-building macro.

Of course, multiple inheritance would help a lot. I'm wondering if this issue is going to be addressed in the near future (otherwise some workarounds would be necessary):

https://github.com/JuliaLang/julia/issues/5

Ralf Hemmecke

unread,
Mar 19, 2014, 8:35:32 AM3/19/14
to juli...@googlegroups.com
> The strong point of Julia are macros, they are very powerful and
> could allow the emulation of type systems of other programming
> languages.

Sorry, if macros are the main reason to choose Julia, then I would ask
whether one needs Julia at all.
Does Julia add something to Python? What is better in Julia compared to
Aldor? Do you have such a list "Why Julia is better than X?" for some
programming languages X?


Anyway. Are you speaking about this?

http://julia.readthedocs.org/en/latest/manual/metaprogramming/#macros

And is this in principle the same as LISP macros?

That's a bit different from Aldor macros, I suppose, because the usual
LISP macro system allows for arbitrary computation (including infinite
loops).

Try to compare with Section 13.1 from the Aldor User Guide.
http://www.aldor.org/docs/aldorug.pdf#page=149&zoom=auto,0,733
Can you tell me how you think macros in Aldor compare to Julia?
In Aldor it's pure substitution, no computation.

> To me, parsing SPAD code is a harder task. But the SPAD compiler can
> drop the parsed AST at various compilation level, as it has been
> pointed out on the FriCAS forum. That is a kind of blessing to know.

Why I find this whole idea of translating SPAD to Julia quite strange
is, that I believe that SPAD is a much more powerful language than Julia
and SPAD/Aldor is tailored towards dealing with symbolic mathematics.

>> But I've seen that Julia can call C code or being called from C.
>> The same applies to Aldor (not to SPAD). So it would be an option
>> to call the Aldor library code from Julia.

> That looks like building a fork of Sage inside Julia. That would be
> an interesting project, too, i.e. not implementing any math at all,
> and have calls to external libraries. Due to Julia's package system,
> this could solve a lot of Sage's portability issues.

:-)

I guess, you don't want just translation SPAD->Julia, but you also want
maintenance of the code. So you will probably want a automatic procedure
that takes to newest code from FriCAS and regenerate the Julia
constructs. (Hard task if you ask me.) Or you do a one-time translation
(partly automatic, partly manual). This would copy all the bugs (of
course). How much manpower and mathematical expertise does the Julia
project have to maintain and improve the generated code in Julia?

If you ask me, going a similar way like Sage, i.e. being a wrapper of
many other opensource maths software, is a much more viable way to get
symbolic math into Julia.

Ralf

Ralf Hemmecke

unread,
Mar 19, 2014, 8:52:10 AM3/19/14
to juli...@googlegroups.com
> Categories look somewhat like traits in Scala, or interfaces in the
> new Java 8, except that they are the types of domains.

Interfaces in Java are similar, but the are weaker.

Try to write MyMonoid from

http://axiom-wiki.newsynthesis.org/ProgrammingSPAD

in Java. And note that it is

1: %

and not

1: () -> %


The difference of the two would be that the first is a constant while
the second is a function with zero arguments. OK, mathematically that's
not a difference, but we all know that functions can have side effects.

> I'm currently pondering about how to emulate them in Julia.

You might want to look into
http://www.sagemath.org/doc/reference/categories/sage/categories/primer.html,
if you don't want to do everything from scratch. ((OK, everyone is going
to simulate the wheel that Aldor/SPAD has builtin.))

> Domain inheritance is also a problem, as only abstract types can be
> inherited in Julia. Again, this can be solved by a type-building
> macro.
>
> Of course, multiple inheritance would help a lot.

Oh, Julia would not allow multiple inheritance like categories in Aldor?
OK, then Julia must have a focus on some area that does not want/need to
say that a ring is at the same time a multiplicative semigroup and an
additive group.

Ralf

Francesco Bonazzi

unread,
Mar 19, 2014, 8:59:19 AM3/19/14
to juli...@googlegroups.com


On Wednesday, March 19, 2014 1:35:32 PM UTC+1, Ralf Hemmecke wrote:

Sorry, if macros are the main reason to choose Julia, then I would ask
whether one needs Julia at all.
Does Julia add something to Python? What is better in Julia compared to
Aldor? Do you have such a list "Why Julia is better than X?" for some
programming languages X?

A brief opinion about my idea of comparisons:
  • Julia is much faster than Python
  • Julia's methods can dispatch the types
  • Julia and Python are both far easier to learn than Aldor
  • Aldor is better suited for a CAS than Julia
  • Julia is better suited for a CAS than Python
Try to compare with Section 13.1 from the Aldor User Guide.
http://www.aldor.org/docs/aldorug.pdf#page=149&zoom=auto,0,733
Can you tell me how you think macros in Aldor compare to Julia?
In Aldor it's pure substitution, no computation.

I didn't mean to port Aldor's macros to Julia. Julia's macros can be helpful to define Aldor's "with" and "add" statements.

That is the primary focus. If you can define a category and a domain constructors inside Julia, and have them behave the same way as in Aldor, then the most difficult part of the work is done.


Why I find this whole idea of translating SPAD to Julia quite strange
is, that I believe that SPAD is a much more powerful language than Julia
and SPAD/Aldor is tailored towards dealing with symbolic mathematics.


Actually, it is strange, I agree.

The fact is, how many people are there who can program in SPAD? Who maintain Aldor/SPAD? Who provide additional packages to Aldor? You see, the power of a language also depends on how it is easy to learn, and on how large the community is.
 

I guess, you don't want just translation SPAD->Julia, but you also want
maintenance of the code. So you will probably want a automatic procedure
that takes to newest code from FriCAS and regenerate the Julia
constructs. (Hard task if you ask me.) Or you do a one-time translation
(partly automatic, partly manual). This would copy all the bugs (of
course). How much manpower and mathematical expertise does the Julia
project have to maintain and improve the generated code in Julia?

If you ask me, going a similar way like Sage, i.e. being a wrapper of
many other opensource maths software, is a much more viable way to get
symbolic math into Julia.


That could be a starting point.

Ralf Hemmecke

unread,
Mar 19, 2014, 9:28:07 AM3/19/14
to juli...@googlegroups.com
> - Julia is much faster than Python

You probably mean that code generated by Julia is faster than code
generated by Python (or rather the respective interpreters work better).

> - Julia's methods can dispatch the types

What exactly does that mean.

> - Julia and Python are both far easier to learn than Aldor

That reminds me of the "hg is much easier to learn than git" discussion. ;-)

Aldor is not really difficult, once you understand the basics. And the
basics I've basically demonstrated on
http://axiom-wiki.newsynthesis.org/ProgrammingSPAD . All the rest is
something that mostly every other language also has.

> - Aldor is better suited for a CAS than Julia

;-)

> - Julia is better suited for a CAS than Python

Can you give some reason why you believe this to be true? What are the
features in Julia that are relevant for CAS and that are more powerful
than or not existing in Python.

> I didn't mean to port Aldor's macros to Julia. Julia's macros can be
> helpful to define Aldor's "with" and "add" statements.

> That is the primary focus. If you can define a category and a domain
> constructors inside Julia, and have them behave the same way as in Aldor,
> then the most difficult part of the work is done.

Right. That's exactly what
http://www.sagemath.org/doc/reference/categories/sage/categories/primer.html
tries to do.

"This design pattern is largely inspired from Axiom and its followers
(Aldor, Fricas, MuPAD, ...)."

> The fact is, how many people are there who can program in SPAD? Who
> maintain Aldor/SPAD? Who provide additional packages to Aldor? You see, the
> power of a language also depends on how it is easy to learn, and on how
> large the community is.

I know that there are only few people that use AXIOM (and followers).
But the reason for this is that AXIOM/Aldor where hidden behind
proprietary licences and additionally hard to learn so that most of the
CAS people turned its back to it and went back to untyped systems like
Maple and Mathematica or invented their own fancy system.

The power of a language does not depend on the community, but it's
rather it's usefulness. If only few people drive cars powered by
electricity instead of petrol and there are only a few recharger
stations, then the traditional cars are still much more useful than
electric one. Does that mean that traditional cars are more powerful?

>> I guess, you don't want just translation SPAD->Julia, but you also want
>> maintenance of the code.

Julia has probably more manpower, but you underestimate the expertise
you need to write a full fledged CAS even if you don't write it but just
maintain it. Finding and correcting bugs needs a whole lot of
mathematical knowledge. As far as I know there are not too many
mathematicians in this world and even less that do symbolic computation. ;-)

Ralf

Theodore Papamarkou

unread,
Mar 19, 2014, 9:47:11 AM3/19/14
to juli...@googlegroups.com
I think the discussion around the usefulness of Julia is irrelevant to the scope of the thread, which is meant to discuss how to develop a framework for symbolic computation in Julia. Imo there are several reasons to prefer Julia rather than other languages, but I won't go down that road so as to avoid strengthening the diversion from the topic of this thread. I will only comment on the fact that the power of a language certainly depends among else on the community (it is not the sole criterion, but it is one). It is not a quantitative matter of manpower only, it has to do with expertise too indeed (there are some mathematicians within the Julia community - by the way a mathematician tends to be a bit hesitant to use the word mathematician when it is not first mathematically defined) and it also has to do with the excitement of like-minded people working together in their community (psychological factors, albeit crucial when it comes to creativity and development, tend to be ignored sometimes by mathematicians).

Francesco Bonazzi

unread,
Mar 19, 2014, 2:12:22 PM3/19/14
to juli...@googlegroups.com


On Wednesday, March 19, 2014 2:28:07 PM UTC+1, Ralf Hemmecke wrote:

>    - Julia and Python are both far easier to learn than Aldor

That reminds me of the "hg is much easier to learn than git" discussion. ;-)


Don't underestimate this factor, especially in open source projects based on volunteer code contributions.

My view is that easier code means greater probability to see new contributors joining the project.
 

Right. That's exactly what
http://www.sagemath.org/doc/reference/categories/sage/categories/primer.html
tries to do.

"This design pattern is largely inspired from Axiom and its followers
(Aldor, Fricas, MuPAD, ...)."


Thanks for this link.
 

The power of a language does not depend on the community, but it's
rather it's usefulness. If only few people drive cars powered by
electricity instead of petrol and there are only a few recharger
stations, then the traditional cars are still much more useful than
electric one. Does that mean that traditional cars are more powerful?


Actually, that's the point, electric cars cause many problems to their owners because of lack of support.

Julia has probably more manpower, but you underestimate the expertise
you need to write a full fledged CAS even if you don't write it but just
maintain it.

That's why I suggested to copy a mature CAS.
 
Finding and correcting bugs needs a whole lot of
mathematical knowledge. As far as I know there are not too many
mathematicians in this world and even less that do symbolic computation. ;-)


Let's point it this way: if Julia will succeed in its aim of becoming a standard for open source scientific computing sometime in the future, then any code written in Julia would greatly benefit from the numerous community. In that case, it is possible that many more people would join a CAS development project, even with minor contributions.

OTOH, if Julia fails in this aim and its usage share remains as it is today, then a CAS written in Julia would be a useless waste of time, as there are other projects with much more possibilities. That is, translation is worth if the Julia community becomes really large.

In the end, I believe that a translation of FriCAS/OpenAxiom to Julia would be beneficial in the first scenario, while in the second one it would be better to create external bindings. Time will tell if Julia will be really spread.

In any case, I came to think that the correct procedure to port Axiom to Julia is

I suggest to keep the translation idea back for some time, and wait to see how both Julia and its community evolve in the future.

Ralf Hemmecke

unread,
Mar 19, 2014, 3:17:18 PM3/19/14
to juli...@googlegroups.com
>> That reminds me of the "hg is much easier to learn than git" discussion.
>> ;-)

> Don't underestimate this factor, especially in open source projects based
> on volunteer code contributions.

Maybe you didn't see my smiley at the end. Some things are harder in the
beginning but yield more power if they are mastered. (But as for git vs.
hg -- now it's only rumours left concerning the lerning curve, but the
power is definitely on the git side.)

> My view is that easier code means greater probability to see new
> contributors joining the project.

I don't underestimate the community. But I personally don't just favour
a project because of many people using it. It must have some novelty in
its own.

> Actually, that's the point, electric cars cause many problems to their
> owners because of lack of support.

Right, their time hasn't yet come. So you understood my comparison.

> (thanks for this link Ralph)

Obviously, it's easier to write 5 letters instead of the correct ones.

Good luck with your CAS effort.

Ralf

Stefan Karpinski

unread,
Mar 19, 2014, 3:57:48 PM3/19/14
to Julia Dev
On Wed, Mar 19, 2014 at 3:17 PM, Ralf Hemmecke <hemm...@gmail.com> wrote:
Maybe you didn't see my smiley at the end. Some things are harder in the beginning but yield more power if they are mastered. (But as for git vs. hg -- now it's only rumours left concerning the lerning curve, but the power is definitely on the git side.)

Git isn't better because it's harder to use. It's better because its basic data model is simpler: it defines everything in terms of tree snapshots and a DAG of commits referencing those, and leaves diffs and efficient storage as an implementation detail. It was a bit of a gamble initially that this would work out well, but it has. Unfortunately, despite its brilliant, simple data model, git has a horrible UI. That is, however, still better than a more complicated and brittle data model wrapped in a slicker UI.

Ralf Hemmecke

unread,
Mar 19, 2014, 4:31:16 PM3/19/14
to juli...@googlegroups.com
On 03/19/2014 08:57 PM, Stefan Karpinski wrote:
> On Wed, Mar 19, 2014 at 3:17 PM, Ralf Hemmecke <hemm...@gmail.com> wrote:
>
>> Maybe you didn't see my smiley at the end. Some things are harder in
>> the beginning but yield more power if they are mastered. (But as for git
>> vs. hg -- now it's only rumours left concerning the lerning curve, but
>> the power is definitely on the git side.)

> Git isn't better *because* it's harder to use.

I didn't say this. What I meant was that git was certainly harder in the
beginning of its existence where there was basically only plumbing code.

Except that I don't believe that the UI is really horrible, I subscribe
to all the rest you say. But unfortunately all this has nothing to do
with CAS in Julia.

Ralf

Stefan Karpinski

unread,
Mar 19, 2014, 4:46:05 PM3/19/14
to Julia Dev
Indeed, we've gotten rather far afield.

Konrad Hinsen

unread,
Mar 20, 2014, 2:56:44 AM3/20/14
to juli...@googlegroups.com
--On 19 mars 2014 14:28:07 +0100 Ralf Hemmecke <hemm...@gmail.com> wrote:

>>> I guess, you don't want just translation SPAD->Julia, but you also want
>>> maintenance of the code.
>
> Julia has probably more manpower, but you underestimate the expertise
> you need to write a full fledged CAS even if you don't write it but just
> maintain it. Finding and correcting bugs needs a whole lot of
> mathematical knowledge. As far as I know there are not too many
> mathematicians in this world and even less that do symbolic computation.
> ;-)

That's exactly what I tried to express earlier. Good to see I am not alone
:-)

Please, everyone, before dreaming about implementing and maintaining a CAS,
have a close look at how these things work. Implement a couple of symbolic
algorithms in the language of your choice, just to get a feel for it. Next,
look at descriptions of some non-trivial standard algorithms, e.g. the
Risch integration for indefinite integrals
(https://en.wikipedia.org/wiki/Risch_algorithm) and consider how you would
implement them.

At that point, you can start to look at a system like Axiom and form an
idea of what it takes to port it to Julia. IMHO, Axiom is way bigger and
more complex than Julia plus all Julia code written to this date.

Konrad.

Theodore Papamarkou

unread,
Mar 20, 2014, 3:46:41 AM3/20/14
to juli...@googlegroups.com
In my opinion, the discussion on the level of mathematical expertise needed for writing a CAS is blowing out of proportions. We are not trying to solve one of the seven millenium prize problems of the Clay mathematics institute neither we are trying to push forward quantum field theory, we are talking about writing a CAS. It certainly requires some level of mathematical knowledge (mostly related to abstract algebra), but it is not all that inaccessible. It certainly requires many hours of work, that most of us don't have, but this is not because of the time needed to acquire so unique mathematical skills - it is because it entails a lot of work in general. There is certainly an issue of manpower in conjunction with mathematical knowledge, but I think we stress the latter excessively. It would "normally" require some people working full-time on this; if they had the time, then I don't think they would have to invest most of it studying maths but rather understand how the CAS is implemented (which can be understood after a short revision or acquisition of some algebraic concepts).

Ralf Hemmecke

unread,
Mar 20, 2014, 4:24:39 AM3/20/14
to juli...@googlegroups.com
> There is certainly an issue of manpower in conjunction with mathematical
> knowledge, but I think we stress the latter excessively. It would
> "normally" require some people working full-time on this; if they had the
> time, then I don't think they would have to invest most of it studying
> maths but rather understand how the CAS is implemented (which can be
> understood after a short revision or acquisition of some algebraic
> concepts).

I don't question that there are bright people in the Julia project, but
there must be a reason why (up to my knowledge) not even the experts at
wolfram.com have put a full implementation of Risch's algorithm into
Mathematica.

Other standard algorithms are polynomial gcd, resultants, polynomial
factorization, Gröbner bases, etc. All these can quickly overflow your
computer, because of intermediate expression swell. So one usually does
not implement them as they are written in books, but rather needs to
look up sophisticated articles that deal with this problem. Also, you
find some standard tricks like computing in homomorphic images and then
lifting, but a good CAS brings all this and more tricks together and as
everyone knows the documentation is often bad or missing. :-(

I guess that is in pricipal not much different from implementing
numerical algorithms (and respective tricks). It's just a different
field of expertise.

Ralf

Theodore Papamarkou

unread,
Mar 20, 2014, 4:44:11 AM3/20/14
to juli...@googlegroups.com
I agree with your points. It is a field of expertise, not anyone can write an Axiom-alike CAS without having this expertise. In your experience, does the FriCAS online documentation serve as an adequate entry point describing in depth the underlying CAS?

Ralf Hemmecke

unread,
Mar 20, 2014, 5:01:56 AM3/20/14
to juli...@googlegroups.com
On 03/20/2014 09:44 AM, Theodore Papamarkou wrote:
> experience, does the FriCAS online documentation serve as an adequate
> entry point describing in depth the underlying CAS?

Certainly not. You get a vague idea of what it does, but even the
current developers have to read the sources and try to make sense out of
the code. It's much easier to do this if one knows a bit of background,
but it's still hard enough.

And what exactly do you need for Julia? Maybe a Julia CAS doesn't have
to be fully general.

But anyway for CAS features, first thing would be a clear specification
of the function that is to write. Then one needs a good idea of what
data structure is best suited for the purpose.

Take, for example, polynomial factorization and Gröbner basis
computations. For the first, it's better to use a recursive
representation of multivariate polynomials, i.e. something like
Q[x][y][z], but that would be totally inefficient for a GB computation.

Such things are implemented, but nobody writes that in the documentation.

Further, the specification is often not done completely rigorously, see
a simple example from a well-known CAS. Other CAS are, of course, not
much better. Unfortunately. :-(

Ralf

================
Looking at http://reference.wolfram.com/mathematica/ref/GCD.html, I find
it a bit hard to guess, what the result of GCD[0,0] actually is.
Starting Mathematica and typing GCD[0,0] returns 0. Well, OK. They don't
give a proper definition of their GCD, but let's assume it's this
(restricted to integers)

GCD[a,b] gives a value d such that
(1) d divides a and
(2) d divides b and
(3) for any other d' with the respective
properties (1) and (2) we have
d' divides d.

In the case of GCD[0,0] we would need a precise definition of whether 0
divides 0. But that's easily true by

a divides b <===> there is a number c such that a*c=b.

Now back to Mathematica.

In[1]:=Divisible[0,0]

Divisible::divz: The argument 0 in Divisible[0, 0] should be nonzero.

Out[1]= Divisible[0, 0]

Ooops. It's unevaluated and it shows an error. Why? If they used this
"Divisible" function in their definition of GCD, then GCD[0,0]
should have returned an error.

But hey, as the (short) documentation Mathematica says:

In[2]:=?Divisible

Divisible[n, m] yields True if n is divisible by m, and yields False if
it is not.

http://reference.wolfram.com/mathematica/ref/Divisible.html

So according to their specification the result is either True or False.
But why then can they return "Divisible[0,0]"? That's neither True nor
False, but rather the unevaluated initial expression. So their
implementation of Divisible does not match their
specification.
====================

Theodore Papamarkou

unread,
Mar 20, 2014, 5:39:16 AM3/20/14
to juli...@googlegroups.com
I am not sure about this, but maybe it is a chicken and egg issue to answer what is needed for Julia, because this depends on which parts of Axiom's CAS can be implemented in it (and which not). I don't have a clear answer to this.

Thanks for the info and your elaborate reply Ralf. I noticed that in your github account you have two repos, namely hemmecke/fricas and hemmecke/fricas-svn. If I want to look a bit into the source code of FriCAS, which of these two repos do you recommend I use?

Ralf Hemmecke

unread,
Mar 20, 2014, 6:40:39 AM3/20/14
to juli...@googlegroups.com
> If I want to look a bit into the source code of
> FriCAS, which of these two repos do you recommend I use?

FriCAS still lives on SVN. :-(
fricas-svn is a mirror of that official SVN repo and updated
automatically with every svn commit. So this is basically to be
considered as a read-only repo, since commits to it are done via SVN.

My "fricas" repo is the one where I sometimes post bugfixes and small
feature branches. All done manually, so my published "master" is often
behind the official one.

You should currently use fricas-svn (master branch). All the other
things are probably too distracting.

In fact, it is quite hard to suggest where you should start reading.
Everything outside of src/algebra is certainly not relevant at first.

In fact, neither SPAD nor Aldor have a lot of types built into the
language, so there is quite some part of the library that introduces all
those types. As you can see from
https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/catdef.spad.pamphlet
first it builds a hierarchy of mathematical structures. These are
"categories" (better think of interfaces than mathematical categories),
which (if at all) only contain generic code snippets that does not
depend on any representation. I don't have a picture of that hierarchy,
but if you want to get an impression, at

http://www.hemmecke.org/aldor

you find an .xfig file for the algebra library that comes with Aldor.
The FriCAS library is much richer, but maybe you get a sense of it.

Once one has the basic structures, one can build other structures, for
example the domain constructor "Fraction"
https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/fraction.spad.pamphlet
constructs rational numbers out of integers.
But as you probably see, at the same time, it can construct rational
functions from polynomials. All it requires is that its argument must
fulfil the promises of an IntegralDomain.

Maybe this would be a good exercise whether it's possible to map
Fraction to Julia in its ful generality. Perhaps then you get a better
feeling of how a translation would look like.

Anyway, I still believe that it would be wiser to call FriCAS as an
external program. In fact, that wouldn't only be good for Julia, but
also for FriCAS. I don't expect that many people would help then in
adding FriCAS features or fixing bugs, but reporting bugs would already
be a first step to make the world better.

Ralf

PS: BTW, I've stumpled acros ijulia. Since I'm looking for a browser
interface for FriCAS, would someone have an idea how I can produce an
ifricas? Would that be difficult?

Theodore Papamarkou

unread,
Mar 20, 2014, 6:54:58 AM3/20/14
to juli...@googlegroups.com
I agree it would be better to call FriCAS as an external program, at least at the beginning, as this would be less error-prone. Your reply is really informative and helpful for the community, a good entry point to start looking at the FriCAS code slowly.

About your question regarding IJulia, I think that Steven Johnson is the most knowledgeable person to reply this question (stevengj on github) - Steven in case you read these lines here, would you like to reply to Ralf about his ifricas question?

Francesco Bonazzi

unread,
Mar 20, 2014, 7:26:43 AM3/20/14
to juli...@googlegroups.com
OK, let's start by an interface to FriCAS. That would still allow to develop extension to FriCAS in Julia, without translating the core of FriCAS.


On Thursday, March 20, 2014 11:40:39 AM UTC+1, Ralf Hemmecke wrote:

PS: BTW, I've stumpled acros ijulia. Since I'm looking for a browser
interface for FriCAS, would someone have an idea how I can produce an
ifricas? Would that be difficult?

I cannot answer this question, but it looks like someone has already ported Aldor to interact with IPython, creating IAldor:

https://github.com/mattpap/IAldor
 

Ralf Hemmecke

unread,
Mar 20, 2014, 7:48:23 AM3/20/14
to juli...@googlegroups.com
> https://github.com/mattpap/IAldor

I know this, but it doesn't work and the author does not reply to my
questions.

Ralf

Francesco Bonazzi

unread,
Mar 20, 2014, 10:28:50 AM3/20/14
to juli...@googlegroups.com


On Monday, March 17, 2014 12:01:37 AM UTC+1, Ralf Hemmecke wrote:
But I've seen that Julia can call C code or being called from C. The same applies to Aldor (not to SPAD).
So it would be an option to call the Aldor library code from Julia.

Is there a way we can build a package in Julia to call FriCAS functionalities?

So SPAD cannot be called from C. Does FriCAS have some kind of API?

Ralf Hemmecke

unread,
Mar 20, 2014, 10:36:07 AM3/20/14
to juli...@googlegroups.com
> So SPAD cannot be called from C. Does FriCAS have some kind of API?

I don't actually know. You should ask the question on the fricas-devel
list. Waldek is probably more knowledgable about this kind of stuff.

Maybe it also depends on what you want. You probably want the answer of
FriCAS be available in a form that Julia can handle. No matter, whether
this will be a string interface or one in C, you have to think about how
to represent these answers in Julia. And that there is no easy solution
in general.

Ralf


Bill Page

unread,
Mar 20, 2014, 10:42:50 AM3/20/14
to juli...@googlegroups.com
SPAD code runs in the FriCAS environment provided by some underlying
Lisp engine (e.g. SBCL), so calling SPAD code from C amounts to
calling Lisp functions from outside of Lisp. This is possible but can
be somewhat complicated. Note that Sage gets around this by calling
the FriCAS interpreter via a pipe, the same way that it interfaces
with Maxima. This has some obvious performance implications which for
most symbolic computations turns out not to be an issue.

Bill Page

unread,
Mar 20, 2014, 11:04:55 AM3/20/14
to juli...@googlegroups.com
This makes very good sense to me. What sort of CAS do you want in
Julia - maybe more than one? I think one important distinction is
between "computer algebra" with emphasis on algebra as such, and
symbolic computation. Axiom, it's derivatives and a few others strong
emphasize abstract algebra implemented as strongly typed objects. At
first blush this seems to resonate with some of the expressed design
goals of Julia.

Other systems such as Maxima (and Mathematica, Maple, etc.) focus on
the significantly less mathematically rigorous but ultimately much
easier problem of manipulating symbols, pattern matching and re-write
rules. This latter sort of CAS is usually much easier for new users
to learn and use but in my experience one eventually appreciates its
limitations.

Ondřej Čertík

unread,
Mar 27, 2014, 2:07:53 PM3/27/14
to juli...@googlegroups.com


On Sunday, March 2, 2014 4:31:01 PM UTC-7, Cristóvão Duarte Sousa wrote:
It is known that "There are those of [Julia main devs] who used Mathematica before we could grow facial hair", so, I guess a CAS in Julia was/is something desired from the beginning, although it has not happened yet.

So far I've found the following packages providing some kind of symbolic manipulation in Julia:

Right now I'm sticking with SymPy.jl (I think PyCall really is a big strength of Julia) and with my "not so carefully written" LinearExpressions.jl when enough.

I had already searched around to see if there was symbolic library in C which could be wrapped into Julia but the only one I found (I don't remember which was now) was not expressive enough to take advantage of Julia type system. CSymPy seems to be designed to be wrapped but it's C++ may be an issue.

Miles Lubin just pointed me to this thread. I plan to add C interface to CSymPy (https://github.com/certik/csympy/) and then wrap this into Julia over this summer while Miles is here at LANL, so that he can help me out if I run into issues.

Has anybody written pure Julia symbolic math for things like:

f = (x**y + y**z + z**x)**100
g = f.expand()

? If so, then we can benchmark it against csympy (once I wrap it) and Mathematica.

Ondrej
 
I also had superficially checked Axiom and thought it seems to have a very nice type system which may be replicable in Julia. Julia rich type system seems perfect to implement many types of symbolic expressions (linear expressions, uni and multivariate polynomials, general expressions) and symbolic variables (reals, matrices, ...), dispatched with its multiple-dispatch which could be complemented with one pattern matching package if needed. One thing I would personally enjoy in a hypothetical Julia CAS would be that it was primarily focused on efficiency (whatever that may mean) rather than featurefulness.

Let me finish linking to this StackOdesinigverflow thread which provided some resources on the design of CAS, being http://www.math.wpi.edu/IQP/BVCalcHist/calc5.html a very good reading.

Cheers,
Cristóvão

On Saturday, March 1, 2014 8:41:19 PM UTC, Francesco Bonazzi wrote:
I have read of discussion of implementations of Computer Algebra Systems on this discussion in the past. I would like to propose a solution which avoids having to reason with the logic of mathematical algorithms.

Axiom is a FOSS computer algebra system, started in 1971, released under the New BSD license in 2001. Since 2007 it has been forked into two projects: FriCAS and Open-Axiom.

http://en.wikipedia.org/wiki/Axiom_%28computer_algebra_system%29

Axiom is written in its own programming language, called SPAD. It is both object-oriented and functional, probably inspired by Lisp. SPAD has been the basis for Aldor, its direct heir, which has more documentation available on the internet (SPAD and Aldor are very similar in their syntax). Technically, Axiom is written in literate programming (LaTeX with code blobs), it is therefore well-documented.

I had a look at Axiom's source code, I think that SPAD has many logical similarities with Julia. Axiom defines mathematical objects (monoids, rings, fields, etc...), functions in SPAD support type-overloading and parametric types (these ones are extensively used). Object methods are defined in a way similar to Julia, even operator overloading supports both forms +(a, b) and a+b.

A possible concern may be SPAD's domains and categories. Roughly speaking, domain is similar to Julia's types with operators overloaded, while categories are abstract types. Unlike Julia, SPAD categories define the methods that domains inheriting them have to implement, so categories look like Java's interfaces or abstract classes.

http://en.wikipedia.org/wiki/Aldor

(by the way, I am wondering whether some of Julia's developers got inspired by Aldor, or whether it is just a coincidence).

The advantages of translating Axiom into Julia are primarily:
  • Julia would have its own Computer Algebra System as a package (example of usage: enable some kinds of symbolic optimization).
  • Axiom has currently few people developing it, due to the steep learning curve of the SPAD programming language (it has very little documentation on the internet, and it is used only in Axiom). Translating Axiom to a more common language would probably boost its development rate, as new developers would find it easier to contribute.
  • Both FriCAS and Open-Axiom are developed on Sourceforge, github would be a more comfortable website.

Maybe a collection of regex could be sufficient to translate Axiom's code (save for possible complications).

Axiom has many mature algorithms, it can symbolically differentiate, integrate, solve ODEs, solve equations and so on. It is still not as powerful as Mathematica.

Cristóvão Duarte Sousa

unread,
Mar 28, 2014, 5:45:28 AM3/28/14
to juli...@googlegroups.com
Hi Ondřej,

As far as I know there is no Julia package which supports such symbolic expressions and manipulation.

About the Julia  wrap over CSymPy, that are very good news!

Cheers,
Cristóvão

Konrad Hinsen

unread,
Jul 3, 2014, 10:06:54 AM7/3/14
to juli...@googlegroups.com
--On 20 Mar 2014 10:42:50 -0400 Bill Page <bill...@newsynthesis.org>
wrote:

> SPAD code runs in the FriCAS environment provided by some underlying
> Lisp engine (e.g. SBCL), so calling SPAD code from C amounts to
> calling Lisp functions from outside of Lisp. This is possible but can
> be somewhat complicated.

I don't know if anyone has tried porting SPAD/Axiom to ECL (which is a
pretty complete Common Lisp implementation). ECL is certainly the most
C-interfacable Lisp around.

Konrad.

Francesco Bonazzi

unread,
Jul 3, 2014, 3:23:13 PM7/3/14
to juli...@googlegroups.com

Aldor can be compiled to object (C-like callable) files. Aldor is the successor to SPAD. I believe that it's better to wait until FriCAS and/or OpenAxiom are ported to Aldor, so it could be possible to access them via Julia's ccall( ).

I believe this way is much simpler than what I had initially proposed.

Bill Page

unread,
Jul 3, 2014, 4:40:03 PM7/3/14
to juli...@googlegroups.com
Yes, FriCAS can be compiled using ECL. Developing a comman-line level
C interface to the FriCAS interpreter would be interesting and useful.
A more intimate interface to directly call FriCAS functions might be
doable but a lot more work because of the need for data conversion.

Bill Page

unread,
Jul 3, 2014, 4:45:16 PM7/3/14
to juli...@googlegroups.com
Although what you say is true, I think it is very unlikely that
FriCAS, OpenAxiom and certainly not the original Axiom project will
ever be ported to Aldor. But a ccall() interface from Julia might
provide some motivation for conversion of some of the FriCAS library
to Aldor so that it can be called from Julia. The problem of data
conversion remains but is perhaps easier than when calling Lisp.
Reply all
Reply to author
Forward
0 new messages