Choose a computer algebra library

[jonc125]

I know David isn't at this stage yet, but it occurred to me that this might be a question which required some discussion & investigation, and would be useful to start early so we don't hold him up!

The thinking was: Given CellML 1.2 removes the directionality of connections, there will need to be more analysis of the mathematical model in order to determine the unknowns and to be able to determine the resulting set of equations and the order in which they may need to be evaluated. My current thinking is that this kind of thing should be handled by some kind of computational algebra system - so hopefully this will just be a matter of finding the right library to use and getting our MathML into that, possibly with some pre-processing. This will also give us the math in a tool that will enable symbolic optimisations & transformations, a la Chaste.

Does anyone have experience of such libraries in C++? I'm only familiar with Python options such as Sage and the underlying SymPy. A brief google search suggests SymbolicC++ as one option.

[agarny]

Good thinking!

I don't personally have any experience with such libraries, so I couldn't recommend one in particular. However, doing also a quick Google search on symbolic mathematics c++ does indeed return SymbolicC++ first, but... its latest version is ~6 years old (which might not mean much, I agree) and it is released under GPL. A GPL license might be an issue on its own?

Another C++ option seems to be GiNaC, which latest version has been released less than 2 weeks ago, but it's also released under GPL.

[dladd]

Thanks @jonc125 - I had begun looking into options yesterday in anticipation of this discussion :-)

I think the Wikipedia list of CASs is probably a good starting point for some of the more mature projects out there.

Criteria I used to sift through these on a first pass:

1. Open-source under an Apache-compatible license (no GPL)
2. Complete/stable/working CAS
3. Under active development: last release in past 3 years and/or last commit in past 3 months
4. Useful and reasonably complete documentation

That reduces the Wikipedia list to a few under modified BSD licenses: Axiom/FriCAS, SyMAT, and SymPy/SymEngine.

• Axiom is still maintained on Github but now seems to be a one-man show. It appears to be extensively documented using "literate programming". The project was also forked into further one-man operations FriCAS and OpenAxiom after an apparent falling out over the development strategy in 2007.
• SyMAT is Java-based and appears to now be focused on their front-end and app development. They also have a more complicated licensing structure, with free licenses only for "personal" use rather than "educational" and "business", which probably rules them out for us.
• SymPy appears to be the most actively developed of these and is a very popular project in general. It is completely written in Python with an additional dependency on mpmath. So we'd probably be looking at going through Cython or using the Python C/API. Another intriguing option from the same team is the relatively young SymEngine (MIT license, previously known as CSymPy), a standalone C++ fast symbolic manipulation library that aims to replace SymPy core and improve performance.

Re: my criterion (1), as @agarny points out, other possibilities are out there are under GPL. GiNaC in particular seems to tick a lot of our boxes as a popular lightweight C++ CAS that focuses on interoperability rather than a high-level interface.

[agarny]

Hmm, I hadn't come across (or noticed) SymEngine in my quick Google search, but it looks like it might be the way to go for me. I quickly cloned their Git repository and was able to build and test things without any problem (just a couple of warnings on OS X). It does, however, require GMP to be available, but I guess that's fine.

So, at this stage, I am personally leaning towards SymEngine.

[jonc125]

Indeed, that does look very promising, and the SymPy community is very active so it's likely to continue. I'm wary of one-man shows having been bitten by that before (the CellML support in Chaste is based on an XML library that hasn't been maintained for years, but I've not had the months spare to port to something else). And we do indeed need to avoid GPL-only libraries.

[dladd]

It might be worth noting that one of the features in SymPy that hasn't made it into SymEngine is a MathML printer. It does seem like development of a MathML parser in SymPy has stalled though.

[agarny]

It might be worth noting that one of the features in SymPy that hasn't made it into SymEngine is a MathML printer. It does seem like development of a MathML parser in SymPy has stalled though.

It might be nice to have, but worst case scenario it would be very easy to write one ourselves, if needed.

[jonc125]

Indeed, and I'm sure they'd be happy to accept an implementation from us for inclusion in SymEngine and/or SymPy!

[certik]

I am one of the SymEngine developers. We'll be happy to have a MathML printer in SymEngine. We can have a parser too. I personally don't use MathML much, but if you have an application for it, we can have a parser as well. There is a latex to sympy parser here: https://github.com/augustt198/latex2sympy

@agarny, regarding GMP, we want to allow to build without it as well (https://github.com/symengine/symengine/issues/713) and instead use some other library like IMath, we just didn't have time to work on it yet. If this is something that you would like, I'll look into that. Let me know.

If you have other wishes that you would like us to implement, let us know.

[agarny]

I am one of the SymEngine developers. We'll be happy to have a MathML printer in SymEngine. We can have a parser too. I personally don't use MathML much, but if you have an application for it, we can have a parser as well. There is a latex to sympy parser here: https://github.com/augustt198/latex2sympy

Thanks @certik, MathML is at the heart of what we are doing, so anything that would help import/export MathML would certainly be welcome.

@agarny, regarding GMP, we want to allow to build without it as well (https://github.com/symengine/symengine/issues/713) and instead use some other library like IMath, we just didn't have time to work on it yet. If this is something that you would like, I'll look into that. Let me know.

I personally know next to nothing when it comes to GMP and IMath, but if one of the two must absolutely be used, then I don't currently have a preference.

If you have other wishes that you would like us to implement, let us know.

Thanks a lot, that's (very) good to know!

[certik]

@agarny We use GMP by default, because it is considered the best and fastest. But it is LGPL, so I wanted to have a build (even if just optional) that doesn't depend on any GPL or LGPL libraries. IMath is BSD licensed, but I never used it. I thought you wanted to use a different library due to the license. If the issue is that we have any dependencies at all, we could in principle provide our own optional (slower, but simpler) arbitrary precision integer and floating point implementations, to allow to build without any dependency. GMP seems like a well managed dependency, it's available on almost all systems, and it's relatively easy to build it from source if needed. And some widely programs like gcc depend on it as well.

Btw, would you mind opening an issue at symengine and report the warnings you saw on OS X? We'll fix it (we test on OS X on Travis, we just need to make sure warnings are turned into errors, so that the test fails).

[agarny]

FWIW, LGPL ought to be fine for us (GPL, on the other hand, would indeed be a problem).

I just built SymEngine from master and it's not so much that I got warnings (my bad), but rather that I got a couple of messages from ranlib. Anyway, and just in case, I have created an issue for it (see issue #935).

[certik]

@agarny perfect, then GMP should be fine for now. Thanks for reporting the issue, we'll have a look.

[hsorby]

This item can now be closed as we have chosen a CAS.

[nickerso]

agreed.