I think, somebody is looking actively at this already: GSoC 2026 | EoM Performance: Profiling Results for KanesMethod (seeking feedback) · sympy/sympy · Discussion #29240 <https://github.com/sympy/sympy/discussions/29240#discussioncomment-15921170>
As I understand Kane, and i am just a user, it simply does not need solve(...) shuvro bhattacharjee schrieb am Mittwoch, 25. Februar 2026 um 20:33:59 UTC+1: > Thanks for correcting me. > my earlier mention of solve() was based on a separate line of > experimentation I was doing outside the Mechanics module, where I > encountered performance issues with expressions involving floating-point > exponents. That investigation helped spark my interest in performance > bottlenecks in symbolic workflows. > > and i also spent some time digging through the source code for both > kane.py and lagrange.py to better understand and found both methods avoid > sympy.solve() during equation generation also verified that both default > to LUsolve for the linear systems. > > If you have any suggestions on specific classes or types of systems .where > you've noticed the most "hang," that direction would be incredibly helpful > for my profiling.I’m actively digging into this as well. > > best regards, > Shuvro > > On Wednesday, February 25, 2026 at 11:34:25 AM UTC+6 [email protected] > wrote: > >> I am unaware of sympy.physics.mechanics Kane’s method using solve to set >> up the symbolic equations of motion for multibody systems. (no idea about >> Lagrange) >> >> Of course I may be wrong. >> >> Did you see any code where solve is used? >> >> >> >> Peter >> >> >> >> >> >> *From:* [email protected] <[email protected]> *On Behalf Of >> *shuvro >> bhattacharjee >> *Sent:* Tuesday, February 24, 2026 10:13 PM >> *To:* sympy <[email protected]> >> *Subject:* [sympy] Re: GSoC 2026: Interest in Performance Profiling for >> Mechanics Equations of Motion >> >> >> >> " Hi Peter, thank you for the question! , by 'solver' I meant the >> high-level sympy.solve() function. Specifically, I’ve been investigating >> performance bottlenecks when equations contain floating-point exponents. >> >> I recently opened an issue (*#29180*) regarding solve() hanging on >> expressions like $x^{5.43}$. I found that the 'hang' occurs because SymPy >> converts these to very high-degree rationals and attempts expensive >> symbolic factorization (Zassenhaus/Hensel lifting). >> >> While my issue was noted as a duplicate of *#11493*, seeing this >> bottleneck firsthand is what motivates my interest in 'Efficient Equations >> of Motion Generation.' In multibody mechanics, empirical force models often >> use such exponents, and I want to ensure the Mechanics package can handle >> or bypass these core symbolic limitations to remain performant." >> >> >> >> On Sunday, February 22, 2026 at 12:09:00 PM UTC+6 [email protected] >> wrote: >> >> I am a user of sympy.physics.mechanics, Kane's method only. >> >> Just curiosity: you say, you have been experimenting with the solver. >> >> What do you mean by solver? >> >> Thanks1 >> >> shuvro bhattacharjee schrieb am Samstag, 21. Februar 2026 um 21:57:40 >> UTC+1: >> >> My name is Shuvro Bhattacharjee. I’m a 4th-year Computer Science and >> Engineering student from Bangladesh, and I’m very interested in >> contributing to SymPy for GSoC 2026. >> >> >> >> I’ve been exploring the project ideas and the one that stands out to me >> is *"Classical Mechanics: Efficient Equations of Motion Generation."* >> I’m particularly interested in this because it combines my background in >> Python with my interest in performance optimization. >> >> I’ve been experimenting with the solver and noticed that some >> expressions (like those with high-degree float exponents) can take a long >> time to process. It made me curious about how we can use profiling to find >> bottlenecks in the Mechanics package, especially when generating Kane's or >> Lagrange's equations. >> >> Also I’ve been looking into the sympy.physics.mechanics module and how it >> handles Kane’s and Lagrange’s methods. >> >> I would appreciate your guidance on how best to get started. >> >> Thank you for your time . I look forward to contributing to Sympy. >> >> Best regards, >> >> Shuvro Bhattacharjee >> >> 1. Best regards, >> Shuvro Bhattacharjee >> >> >> 2. >> >> >> >> 1. Best regards, >> Shuvro Bhattacharjee >> >> >> 2. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/sympy/86c58776-4b5d-4794-be18-440245e59dd5n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/sympy/86c58776-4b5d-4794-be18-440245e59dd5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/7edff1fc-1ea8-4199-8d63-fed4f9af48f7n%40googlegroups.com.
