Symbolics.jl VS JET.jl

It’s not up to parity with SymPy/Matlab by far yet - here’s the tracking issue on it https://github.com/JuliaSymbolics/Symbolics.jl/issues/59

Hello Juila Community. This is my second day working with Julia, having come over from Sympy due to performance reasons. I am working on a project that requires calculating matrix determinants and adjugates for families of matrices with symbolics entries. I am using Symbolics.jl for the symbols and using Juilia 1.8.2.

After spending some time reading the documentation, it turns out that JuliaSymbolics also lacks factorizations functionality (according to [Link](https://github.com/JuliaSymbolics/Symbolics.jl/issues/59))

You can also get an expression for the partial of β with respect to h using Symbolics.jl:

The example is applied to the right-hand side of a generated mass-matrix ODE (DAE) which is then solved using the adaptive time stepping methods of DifferentialEquations.jl. It's a test example that comes from the robotics / rigid body dynamics simulation groups (specifically interested in control) where they before were generating the governing equations with SymPy, and recently switched to try Symbolics.jl (and we got the example because of some performance issues that needed fixing). The comparison is with and without applying the code simplifier before solving. The table shows an average global induced error of 1e-12 when chopping off the 1e-11 * sin(x) terms and smaller. Thus there's nothing "competitive" against standard adaptive time stepping here: it's used to enhance the simulation of generated models that are simulated with the adaptive time steppers.

Done. https://github.com/JuliaSymbolics/Symbolics.jl/issues/215

An informative discussion on julia forum. Have you tried using https://github.com/aviatesk/JET.jl to minimize type instabilities?

For instance, https://github.com/aviatesk/JET.jl is still in its relative infancy, but it's played a big role in detecting quite a few potential bugs that had never been reported to use by users or caught in our testing infrastructure. There's also been a lot developments like interfaces to RR the time travelling debugger https://rr-project.org/ which helps us better understand and catch some very hard to debug non-deterministic bugs.

Have you seen Shuhei Tadowaki's work on JET.jl (?)

If you're curious: https://github.com/aviatesk/JET.jl

This may seem more about performance (than IDE development) but Shuhei is one of the driving contributors behind developing the capabilities to use compiler capabilities for IDE integration -- and indeed JET.jl contains the kernel of a number of these capabilities.

This is sort of being done right now, as dynamic languages have begun to adopt gradual typing... at least Python and Julia, that I know of.

If something like [JET.jl](https://github.com/aviatesk/JET.jl) become ubiquitous in Julia, one could add a function that pointed out all the places in the code where types are not fully inferred by the compiler.

It'll never be quite the same level of safety as a static language, however.

- Pattern matching (sometimes you don't want the overhead of a method lookup)

[1]: https://github.com/aviatesk/JET.jl

You can use the `@code_warntype` macro to check for type stability, which is very helpful for detecting such performance pitfalls on single function level. In the future, https://github.com/aviatesk/JET.jl may give a more powerful way to do it.