Why are there both table and explicit solver in DifferentialEquations.jl?

Yes, in most cases tables are not used. In fact, tables are only used if you use the method ExplicitRK(tableau=...)

. You can see the convergence tests on each of them in the DiffEqDevTools tags , but other than that they are not commonly used.

The reason for this is that the table based implementation is not as efficient. Getting rid of indirection caused by using pointers to constants has a measurable impact on runtime. Sure, in the asymptotic limit, when the user f

is extremely costly, the implementation details won't matter, but most real world cases are not in that limit, as real benchmarks show (in this limit, you should use multi-step aynways methods). Thus, there are hard-coded versions of the most efficient Runge-Kutta methods with higher order hard-coded interpolation schemes, since they are workhorse methods and should be as efficient as possible.

So why do these tables exist? I find it important to note that DifferentialEquations.jl is not just a software package for using differential equations, but also a software package for developing and testing new methods. This is evidenced by the testing features in devdocs . For algorithms that have more efficient implementations, tables still use engineering because all tables have the same implementation, and thus provides an easy scientific way to determine true efficiency between methods. Not only do tables allow for performance comparisons, but then you can also compare areas of stability with plot recipes:

plot(constructRK4())

      

        
        
        
      

    

This large library of tables has been used to comb all the RK methods and create a modernized selection. I posted some random entries written about this and documented some of the details in more detail in a CompSci SO post . All of these experiments were conducted using development tools.

At the end of the day, DifferentialEquations.jl is truly unique because it's not just a re-implementation of what you've seen before. One of the obvious changes in the preceding is that the method of selecting the 4/5 Runge-Kutta is not steam-Prince Dormand DP5

, in MATLAB or SciPy (which is merely a wrapper dopri5

), but using modern cryptosystem: Tsit5()

. This is because this later method theoretically achieves a lower error when the estimated costs are equal, and devtools have confirmed this. Other things in DifferentialEquations.jl that are unique, its adaptability for stochastic differential equations , higher order methods for delay differential equationsetc., and there is still a lot of research to be done (things in private repositories before publication). Most of them are made possible (or at least easy to do) because of the associated development package.

So I think this clearly shows that the philosophy of DifferentialEquations.jl is not like a set of differential equations in other languages ​​/ libraries. In other suites like MATLAB or SciPy, most of the time, the goal is to give you a few basic methods that are usually useful. Efficiency is not necessarily a goal (a good example of this is Champin's choice of not having high-level RK methods in MATLAB), and completing a "standard" implementation is usually good enough (SciPy is just wrappers). Simplicity and standards make sense for these software packages.

But DifferentialEquations.jl focuses on developing new methods for handling today's computationally complex equations and using these new methods to solve problems that were previously unattainable. Because of this different focus, there are some options that are made different. For example, having large pools of methods / implementations is good here because it allows users and researchers' methods to compare algorithms and figure out how to continually improve and choose them (I suggest users test table methods on their problems and see if some obscure RK method works well ). I make sure the most effective research tools are available and deal with the complexity by providing default users and users. If any part of the recommendation is in unconfirmed documentation,please open a question so we can discuss how to improve the documentation. But I see leading users "fix" method choices as a documentation problem, not a problem that should hold back design, capability, or efficiency.

I will cover the philosophy behind DifferentialEquations.jl in upcoming blogs, but that's the gist. I don't think this is a very important question because it is a more personal question for me as to why I keep using inefficient methods (as it is not recommended!), And I hope this gives an informative answer.