Python sympy vs Mathematica for Lagrangian Mechanics

I compare calculating the trajectory of a triple pendulum in both python (running on Google's colab) and Mathematica (running on the wolfram servers).

I would appreciate any help anyone could give to make the comparison better. Right now there's about a 100x speed increase doing this in Mathematica.

[BrettSam]

I realize I am late to the party, but one thing that has sped up my sympy code is, when I make my symbols, make sure to set the real and positive assumption whenever it is correct to do so:

l1 = smp.Symbol("l_1", real=True, positive=True)
the1 = smp.Function(r'\theta', real=True)(t)
#... and so on

By default, sympy will make no assumptions about your symbols, so maybe they are complex, and that slows simplification down considerably. If you have square roots of things getting squared, knowing that those things are positive can allow for better simplification.

Likewise, the lambdified routines might be extra complicated to allow for possibly complex numbers.

This has sped up my code considerably. Hopefully it will help you too!

[absurdengineering]

Mathics3 may be of interest too. It's just a small subset of Mathematica, but it's already a fairly impressive project.

[Michallote]

Mathematica is fundamentally different from Python. Everything in Mathematica is a symbolic variable and that's why it is heavily optimised to manipulate expressions quickly. However the lack of proper data structures in Mathematica makes data science and data manipulation a nuisance. It is also extremely slow in this front compared to other frameworks.

Python on the other hand is almost a general purpose programming language. In python everything is an object instead. Which means it is customisable to the end of the world. Numpy, then, is the framework that tries to mimic other scientifical computational software, specifically MATLAB by allowing the use of vectorized operations such as adding arrays without loops.
However MATLAB is very limited by that same reason. Everything in MATLAB is an array (even scalars). Which also makes matlab terrible for algebraic symbolic manipulation.

[Andrew_J]

Maybe try Julia? Matlab-esque syntax and C++ speed. Apparently solid for DE's and other things. For graphing you can import pythons matplotlib (in Julia).

[willmorris]

Andy,

Your results do not surprise me. Python sacrifices computation speed for generality and user-friendliness. There are workarounds, i.e., using a Python interpreter with complied dependencies originally written in C++ for example, but these solutions are usually enterprise level in my experience, and not practical to develop for your typical research end-user. If you solve computationally-intense problems often, it's probably best to stick to programs specifically designed for that task, like Mathematica or MATLAB.

[vishalramnath]

The declaration of the symbolic function the1=smp.symbols(r'\theta, cls=smp.Function') with the symbolic class is a neat trick. I understand your intention is to leverage the symbolic capability to avoid tedious hand calculations/derivations. I agree the Mathematica codes seems much more compact but I think the Python notation seems easier to read. Is there any meaningful difference in the Python odeint solver from a regular Matlab ode45 Runge-Kutta solver? Does odeint for example toggle for stiff differential equation systems?

[kikoiekiko]

have you ever tried sagemath? might help you with this situation