[ANN] SymbolicIntegration.jl - indefinite integration with Symbolics.jl symbols

Package Announcements
, ,
21

I see, thanks for clearing up. BTW older versions seem to apply the rule, so this may be a regression?

(@v1.12) pkg> st SymbolicUtils
Status `~/.julia/environments/v1.12/Project.toml`
⌃ [d1185830] SymbolicUtils v3.32.0
I
julia> using SymbolicUtils

julia> r = @rule ~a*~b + ~a*~c => ~a * (~b+~c)
~a * ~b + ~a * ~c => ~a * (~b + ~c)

julia> @syms a::Real b::Real c::Real
(a, b, c)

julia> r(b*a + b*c)
(a + c)*b

julia> r(c*b + a*b)
(a + c)*b

julia> r(b*c + a*b)
(a + c)*b

julia> r(c*b + b*a)
(a + c)*b
3 Likes
22

When I go to web page https://docs.sciml.ai/SymbolicIntegration/stable/, where one normally clicks to jump to GitHub, it looks like this:

image
image684×177 7.6 KB

So – a search fields is located on top of the GitHub, etc links, and it is not possible to click to GitHub on my Windows 11 64bit Lenovo Yoga 9i 2in1 (Lunar Lake, 2025 model).

So I am not able to check which is the latest released version of SymbolicIntegration.

In the Julia Package Manager, with the latest version of Julia and all packages updated, it seems like SymbolicIntegraion v. 3.2.0 is the current one.

Doing using SymbolicIntegration takes some 16-17 minutes to complete, when run on battery.

23

There must be something wrong on your laptop or SW configuration. I get:

(tmp) pkg> st
Status `~/tmp/Project.toml`
  [315ce56f] SymbolicIntegration v3.3.0
  [0c5d862f] Symbolics v7.4.1

julia> @time using SymbolicIntegration
  3.246592 seconds (2.59 M allocations: 152.118 MiB, 6.23% gc time, 7.42% compilation time: 51% of which was recompilation)

using Julia 1.12.3 on Ubuntu 24.04 on a AMD Ryzen 7840U laptop on battery.

OK, I see you do not have the latest version of SymbolicIntegration.

Please, as first step delete all packages that you currently do not use from your global environment.

  • Start Julia with julia
  • Enter the package manager with ]
  • The command st shows you which packages are installed
  • The command rm <PACKAGE_NAME> can be used to remove unused packages
  • The command up can be used to update the remaining packages

Then create a new project:

mkdir test
cd test
julia --project=.
using Pkg
Pkg.add("SymbolicIntegration")
Pkg.add("Symbolics")
Pkg.update()

This should give you the latest package versions.

2 Likes
24

Maybe you could make a Julia version of the famous https://www.integral-calculator.com/ since it’s basically just doing a Risch method

2 Likes
25

I found the culprit: ControlSystemsMTK holds back Symbolics to v.6.58, and then I can only install SymbolicIntegration at v3.2.0. When I remove ControlSystemsMTK, Symbolics can upgrade to v7.4.1, and that enables the installation of SymbolicIntegration@3.3.0.

With this update, using SymbolicIntegration is more or less instantaneous, and there is no visual installment of rules.

If I re-add ControlSystemsMTK again, this downgrades Symbolics back to v6.58, and so on.

1 Like
26

Feel free to create an issue in ControlSystemsMTK and request that the Symbolics dependency be updated to the latest version.

27

This update is currently blocked due to a bug in MTK

2 Likes
28

Thanks for raising this issue. It’s a known limitation of our current rule system - the associative-commutative matching is “not associative-commutative enough.” The problem is that when matching

@rule ~a*~b + ~a*~c => ...

against

a*b + a*c

The + matcher will assign ~a * ~b to a * b and ~a * ~c to a * c. Sometimes, the * matcher for the first term will match

~a => b
~b => a

Which is a valid matching of ~a * ~b to a * b. Using this matching, the + matcher recurses into the second term, which tries to reconcile ~a * ~c with a * c but is unable to do so. The + matcher then swaps the order of the terms, matching ~a * ~b to a * c and ~a * ~c to a * b. This fails in a similar manner, and the rule fails to match.

The “sometimes” above is somewhat stochastic because it relies on the hash order of a and b. If we store a * b as (*, [a, b]) (i.e. if a hashes to an earlier slot in the hash table than b) then it’ll match ~a => a, ~b => b and succeed. If we store a * b as (*, [b, a]) then this won’t happen, and the rule will fail.

The missing piece is for matchers earlier in the call stack (+) to recognize that deeper matchers (*) have more permutations to try.

29

No problem – I understand this difficulty. And I am not using ControlSystemsMTK at the moment (i.e., the next couple of weeks), so I can wait. Also, I do not use SymbolicIntegration.jl daily, so I can probably remove it temporarily – if needed.