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

**URL:** <https://discourse.julialang.org/t/ann-gruntzlimit-jl-rischintegrate-jl-rubisymbolicintegration-jl-symj-jl/140334>\
**Category:** Package Announcements\
**Created:** [October 29, 2026, 10:48am UTC](https://discourse.julialang.org/t/ann-gruntzlimit-jl-rischintegrate-jl-rubisymbolicintegration-jl-symj-jl/140334 "2026-10-29T10:48:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![j\_verzani](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j_verzani/32/8551_2.png) [@j\_verzani](https://discourse.julialang.org/u/j_verzani)\
**Post date:** [October 29, 2026, 10:48am UTC](https://discourse.julialang.org/t/ann-gruntzlimit-jl-rischintegrate-jl-rubisymbolicintegration-jl-symj-jl/140334/1 "2026-10-29T10:48:38Z")

</div>

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](https://github.com/jverzani/SymJ.jl)) 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](https://github.com/jverzani/SymJ.jl/blob/main/notes/feature_audit.md). 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.