DifferentialEquations.jl VS DiffEqOperators.jl

This lists some of its unique abilities:

https://docs.sciml.ai/DiffEqDocs/stable/

The routines are sufficiently generic, with regard to Julia’s type system, to allow the solvers to automatically compose with other packages and to seamlessly use types other than Numbers. For example, instead of handling just functions Number→Number, you can define your ODE in terms of quantities with physical dimensions, uncertainties, quaternions, etc., and it will just work (for example, propagating uncertainties correctly to the solution¹). Recent developments involve research into the automated selection of solution routines based on the properties of the ODE, something that seems really next-level to me.

[1] https://lwn.net/Articles/834571/

https://github.com/SciML/DifferentialEquations.jl/issues/786. As you could see from the tweet, it's now at 0.1 seconds. That has been within one year.

Also, if you take a look at a tutorial, say the tutorial video from 2018,

It's not faith, and it's not all from Julia itself. https://github.com/SciML/DifferentialEquations.jl/issues/785 should reduce compile times of what OP mentioned for example.

Let's even put raw numbers to it. DifferentialEquations.jl usage has seen compile times drop from 22 seconds to 3 seconds over the last few months.

https://github.com/SciML/DifferentialEquations.jl/issues/786

https://github.com/SciML/DifferentialEquations.jl/issues/737 double posted, with the answer here. Please don't do that.

>I hope those benchmarks are coming in hot

M1 is extremely good for PDEs because of its large cache lines.

https://github.com/SciML/DiffEqOperators.jl/issues/407#issue...

The JuliaSIMD tools which are internally used for BLAS instead of OpenBLAS and MKL (because they tend to outperform standard BLAS's for the operations we use https://github.com/YingboMa/RecursiveFactorization.jl/pull/2...) also generate good code for M1, so that was giving us some powerful use cases right off the bat even before the heroics allowed C/Fortran compilers to fully work on M1.

(b) DiffEqOperators.jl is being worked on https://github.com/SciML/DiffEqOperators.jl/pull/467 .

I like that they are colored now, but really what needs to be added is type parameter collapasing. In most cases, you want to see `::Dual{...}`, i.e. "it's a dual number", not `::Dual{typeof(ODESolution{sfjeoisjfsfsjslikj},sfsef,sefs}` (these can literally get to 3000 characters long). As an example of this, see the stacktraces in something like https://github.com/SciML/DiffEqOperators.jl/issues/419 . The thing is that it gives back more type information than the strictest dispatch: no function is dispatching off of that first 3000 character type parameter, so you know that printing that chunk of information is actually not informative to any method decisions. Automated type abbreviations could take that heuristic and chop out a lot of the cruft.