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, but I agree it should not be conflated 
with how Kane’s method itself is implemented.  

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/2db6ffbf-bbd9-4879-9853-3af130790982n%40googlegroups.com.

Reply via email to