[ANN] GruntzLimit.jl, RischIntegrate.jl, RUBISymbolicIntegration.jl, SymJ.jl

Package Announcements
,
1

New packages, mostly generated with assistance from Claude. These started as an experiment to see how much work it would be to generalize SymbolicLimits.jl and SymbolicIntegration.jl beyond SymbolicUtils.jl to any symbolic type supporting just the TermInterface.jl contracts.

GruntzLimits.jl has better coverage (it is on par with SymPy.jl and Giac.jl) and better performance than SymbolicLimits on SymbolicUtils types and, as the Expr type is supported in TermInterface.jl can be used with or without a symbolic package. (the @limit macro).

In generalizing SymbolicIntegration.jl, which implements both rule-based and Risch-based methods, there are two packages. RUBISymbolicIntegration.jl can integrate a few more integrals than the RulesBasedMethod of SymbolicIntegration.jl, but slower. It’s only plus is the extra generality.

However, RischIntegrate.jl can do significantly more integrals than the Risch-based method of SymbolicIntegration.jl. The package implements algorithms from Bronstein’s transcendental functions book in addition to work on algebraic integrands, and integrands with special function answers. Using a test set of 1680 integrals compiled by SymbolicIntegration.jl, RischIntegrate.jl is finding success with over 99% of them. This exceeds either Giac.jl or SymPy.jl. Performance exceeds SymPy.jl, but not Giac.jl. Again, there is a macro, @integrate, to integrate using Expr objects, so no symbolic package is needed. There is still work to do, as the full 72k+ set of sample problems of RUBI highlight areas of improvement and that the package trails the commercial CASs.

Finally, SymJ.jl (unregistered for now, and at GitHub - jverzani/SymJ.jl: A symbolic manipulation kernel for Julia: one concrete, hash-carrying node type, exact numbers, canonical sums/products/powers built as you go, callable expressions, and the TermInterface v2 contract · GitHub) is an attempt to provide a more traditional CAS than Symbolics.jl built in Julia. Symbolics.jl has proven itself as a fundamental part of the Julia ecosystem. SymJ.jl is an attempt to provide a Julia-only alternative for users of SymPy.jl with its underlying expressions manipulated with the performance level of SymEngine.jl. Earlier conversations on discourse about why do a CAS in Julia are still valid, but it was interesting to me how far an LLM can go in about a week of care and feeding. An audit of implemented features compared to Giac and SymPy can be seen at SymJ.jl/notes/feature_audit.md at main · jverzani/SymJ.jl · GitHub. Performance on a sampling of tasks is better than Symbolics.jl and SymPy.jl, though beaten by Giac.jl in many areas.

All four packages have a badge in their README linking to a comparative report on their performance (coverage and timing) on a range of problems with detail on each.

2

Thank you! I have been trying SymJ today and it’s fantastic. I hope that very soon I will be able to get rid of conda (and my life will be happier).

3

Thanks @j_verzani
I didn’t saw your ANN previously and have written you privately but wanted to thank you publicly both for your very fair comparison with Giac.jl and for your work in the open source CAS field.

4

Thank you for this package. It is superb. More power to your elbow.
Please I notice that SymJ does not display the symbols correctly in Jupyterlab notebook. It seems it has issue with Latexify.jl.

20

Just to add, but perhaps the moderators should make a thread split? I feel like we are getting quite far away from talking about the cool new packages that were the point of this post.

22

Please register this package (SymJ.jl). Its SymPy-like approach and syntax make it a good CAS for Julia. It is superb and very fast. It will be nice if it can work with Symbolics.jl like the SymbolicsMathLink.jl.

23

Since my old comment got moved over, I’ll restate the relevant bit here.

I’m really excited to see the new symbolic integration packages. SymbolicIntegration.jl was a GSOC project that worked out pretty well in my opinion. I haven’t really kept up with it, but new symbolic integration packages are a win in my book.
SymJ.jl is interesting, I’m curious to see how it represents expressions internally. Maybe SymbolicUtils.jl can learn a few new tricks.

I also agree that SymJ.jl should be registered. I would like to use it in Symbolics/SymbolicUtils for some algorithms where we are suboptimal. Interop would also be nice, along with including it in our benchmarks. Happy to collaborate on both those aspects.