Symbolic computation in Julia with lisp/reduce; and calling Julia from LaTeX

package
proposal

#21

Thanks! Looks nice. I am interested to see where this goes.


#22

Computer algebra systems & Julia…

I’m curious about the status. I tested Macsyma ca. 1987, used Mathematica ca. 1988-1992, then Maple ca. 1992-1995, then MuPad a little around 2005, and SymPy occationally. I’ve been aware of Reduce, Derive, Gauss, Maxima, etc.

I liked Mathematica for its systematic naming convention and good graphics tools, but found Mathematica expensive, the multiple programming paradigms confusing. Big plus for physics approach and well written literature. I liked Maple for its simple programming paradigm, and it was reasonably priced. Way back, Maple had simple graphics. Maple intro literature was oriented towards mathematicians, starting with examples using algebra over fields, etc. – which I found terse. MuPad was a modernized version, somewhat similar to Maple – but less well developed then (now owned by MathWorks). Was it Derive or Reduce that was used by HP in their CAS tools (calculators, etc.)? Gauss was an IBM product, I think.

My main interests in CAS as part of Julia?

  • Basic operation on symbolic expressions (simplify, collect, expand, etc.)
  • Calculus: Differentiation, Taylor series, Jacobians, etc., Integration. Differentiation of functions.
  • Solving sets of algebraic equations. Substitution, etc. Linear algebra.
  • Groebner basis computations – could perhaps just as well be done directly in Julia.
  • Smith form of rectangular systems (Maple can; last time I checked, MuPad/MATLAB could only do square systems :frowning: ) – could perhaps just as well be done directly in Julia.

User interface?

  • SymPy… somewhat difficult to find indexed documentation (is there rectangular Smith form? Groebner basis?). “Complex” user interface?
  • Symata… I like the idea that one switches prompt (switching between julia> and symata>). This removes the complexity of defining variables in Julia; in the symata> environment, this is handled in a natural way. I like the idea of trying to use Mathematica’s systematic syntax, but it is not 100% compatible, which makes some documentation needed. Important questions: how can symbolic expressions in symata> be transferred to julia>?

I just dug out a Maple license to compare a model of a simple, mechanical system, described using Lagrangian mechanics and comparing it to that of Hamiltonian mechanics. The equations from Lagrangian mechanics were simple to develop; the Hamiltonians were surprisingly complex to do by hand calculation, so I gave up and used Maple for that.

It would have been useful if I could specify the Lagrangian in a Julia CAS, automatically generate optimized Euler-Lagrange equations or Hamiltonian equations in the CAS, and export the equations from the Julia CAS (SymPy, Symata, Reduce, etc.) back into a Julia function for use in a DifferentialEquations package or as LaTeX code…

Anyway, this is an interesting subtopic for Julia, in my view.


#23

If you are interested, you are very welcome to help with https://github.com/dalum/Sylvia.jl :smile: The hope is to make a package that is light–weight with no binary dependencies, lives inside the Julia ecosystem, rather than try to be a full–blown CAS in itself, and easily translates expressions into Julia code. It is very poorly documented at the moment, but I hope to fix that over the next weeks.


#24

Try out Reduce.jl and see if it does what you need… it does most of what you described and is a lot further along now than when this thread originally was started.

REDUCE itself is implemented in its own programming language called RLisp… one of my other plans is to implement the parser for it, implementing the reduce langauage directly into Julia. I think Julia is very well suited for natively doing symbolic CAS, but it will take effort to have all these kind of features. One way is to parse the RLisp language and interpret the hundreds of thousands of lines of REDUCE source into Julia directly, instead of using the binaries directly.

Sylvia looks very promising too, I have been keeping an eye on it, along with some other similar projects.


#25

I’m not really a developer; I haven’t had time to start using “Git” yet :blush: – if I do some development, it would probably rather be in application/control, etc.


#26

Hi Chakravala: Is there a recent manual for Reduce? I found one in PDF format from 2004 – is that the latest one? (I actually prefer PDF format; I’m so old that I prefer to print material for reading in a cafe…). According to the manual, there is a Reduce package NORMFORM that does Smith normal form for rectangular matrices/pencils. There is also a Groebner package.

It would be useful if your documentation for Reduce.jl includes references to the latest available Reduce material, and say a few words about whether additional packages (??) such as NORMFORM and Groebner works with your system – and if so, if anything extra has to be done to make it work…


#27
  • Here is a notebook with examples of the Julia-Symata interfaces You can also try ? Compile (The prototype is correct, but the example is out of date). Here are similar notebooks.

  • How closely to follow Mathematica syntax and semantics is an important question. At present, Symata breaks with Mathematica in many respects out of neccessity. Following SymPy is much less labor intesive.The overall project (like many or most others) is already extremely labor intensive.

  • I’m not sure if you are referring to the Smith normal form. Here is a gist that appears to use sympy and rectangular matrices. Maybe this helps. It is the first result returned by googling smith normal form sympy.


#28

Thanks. You are right – I was referring to the Smith normal form (I should have been more precise)… The Smith normal form is used in studies of zeros and poles in MIMO linear control systems, or rather: the Smith-McMillan form, which is simple to implement if one has the Smith algorithm…


#29

I guess the “smith.py” is not native in SymPy. Does that mean that for Symata, the same function should be written as a Julia function? Or should it be written as a Python function and placed in some mysterious subdirectory in Julia?


#30

OK… I found a Reduce user’s guide from 2018… https://reduce-algebra.sourceforge.io/manual/manual.pdf


#31

Yes, indeed you can load it in Julia with load_package(:normform) and you can send it Reduce commands. However, I have not implemented any special methods that correctly parse the output of those methods. This wouldn’t be too much extra work to implement, but I don’t know when I have the free time for it.

This is a package that gets automatically loaded and called as needed for functionality, I believe.

You can find a list of current support for the built-in REDUCE packages on the ReduceAlgebra.jl page

Technically, you can load all other packages also, but I don’t have specific interfaces implemented for them unless they are currently listed on that page. That page also has links to PDFs and HTML docs.

Luckily, it is very easy to contribute extra interfaces for more REDUCE packages (since there is a parser generator and lots of built-in features that help), so this would be a place to start in terms of contributing to a git repository. An example of how to do it is the ReduceLinAlg package that I have published as an example https://github.com/JuliaReducePkg/ReduceLinAlg.jl


#32

By “not native” I guess you mean not in the sympy distribution. I don’t know of a turnkey way to include code like this. It’s not clear if there is a universally best way in this case. Translating expressions between Symata and sympy is slow, and is often the bottleneck. So maybe wrapping the python code in the gist is the way to go. I have not written a tutorial on how to do this; in fact, I haven’t tried it, although it’s not difficult. I don’t know how systems are specified for DifferentialEquations, so I don’t know if the existing Julia-Symata interfaces are enough. As you can see, there is a lot of software and a huge number of possibilities for building symbolic tools with it. The only things lacking are the usual in open source; buy-in, organization, long(ish)-term design, and developer-hours.