3 ms·

Cheers but I already have my own solver, by implementing this approach https://projecteuclid.org/euclid.em/1120145574 https://projecteuclid.org/euclid.em/112014

Cheers but I already have my own solver, by implementing this approach https://projecteuclid.org/euclid.em/1120145574 https://projecteuclid.org/euclid.em/1120145574 ;) Just wondering though . . .

TheGallopedHigh 7y ago
Interesting. Do they go on to compare it to standard methods? Ie what’s the big benefit here?
- ChrisRackauckas 7y ago
  That paper needs an update. Taylor methods utilize AD effectively to get something that seems efficient. But there's a lot of theory to explain why they aren't efficient in practice, mostly because of truncation error coefficient sizes. Also, since the time of the article, there have been much better high order explicit RK methods that have been derived, and improved schemes for adaptive order explicit extrapolation. When we benchmark these against Taylor methods which use an optimal form of AD (provided by TaylorIntegration.jl), we still see about a 10x performance difference when at the edge of Float64 range: https://benchmarks.juliadiffeq.org/html/DynamicalODE/Henon-Heiles_energy_conservation_benchmark.html https://benchmarks.juliadiffeq.org/html/DynamicalODE/Henon-H... https://benchmarks.juliadiffeq.org/html/DynamicalODE/Quadrupole_boson_Hamiltonian_energy_conservation_benchmark.html https://benchmarks.juliadiffeq.org/html/DynamicalODE/Quadrup... As you get outside of Float64 range, the parallelized explicit extrapolation methods seem to do better. This is something we're going to be getting a lot more precise benchmarks in JuliaDiffEq now though, since we have optimized generic implementations of each of the methods and can thus use Float128 and arbitrary precision on all of the methods simultaneously to really figure out the cutoff. But thinking about efficiency and accuracy misses the point of Taylor methods. The Taylor methods have a way of getting rigorous error bounds on the integration (like interval arithmetic, but for the continuous ODE), which is the real reason why they can be useful, with the extra cost of course.
  - m4r35n357 7y ago
    Erm, sure I know that name from somewhere! I won't dispute your claims about alternative methods, but I've found it hard to find any open documentation about this stuff, so I am unaware of it myself. Then again, I hereby announce that I am an _amateur_ at this, so I'm not taking criticism personally! In fact one of the reasons I wrote my stuff (FWIW in c and Python) is because I couldn't follow the code in TaylorIntegration.jl ;) My stuff is _really_ simple, and I know _exactly_ how it works.
- m4r35n357 7y ago
  High order means much less dependence on step size. Automatic (exact) differentiation means no roundoff from finite differences with small step size. They use a very clever and involved code generation approach, I have just hardcoded the recurrences in my implementation (much simpler). https://github.com/m4r35n357/ODE-Playground https://github.com/m4r35n357/ODE-Playground It is not a black box approach like RK4, it depends on the model using a (hardly at all) restricted set of functions. Piecewise definitions are OK though.

Cheers but I already have my own solver, by implementing this approach https://projecteuclid.org/euclid.em/1120145574 https://projecteuclid.org/euclid.em/1120145574 ;) Just wondering though . . .

TheGallopedHigh 7y ago

Interesting. Do they go on to compare it to standard methods? Ie what’s the big benefit here?

ChrisRackauckas 7y ago
That paper needs an update. Taylor methods utilize AD effectively to get something that seems efficient. But there's a lot of theory to explain why they aren't efficient in practice, mostly because of truncation error coefficient sizes. Also, since the time of the article, there have been much better high order explicit RK methods that have been derived, and improved schemes for adaptive order explicit extrapolation. When we benchmark these against Taylor methods which use an optimal form of AD (provided by TaylorIntegration.jl), we still see about a 10x performance difference when at the edge of Float64 range: https://benchmarks.juliadiffeq.org/html/DynamicalODE/Henon-Heiles_energy_conservation_benchmark.html https://benchmarks.juliadiffeq.org/html/DynamicalODE/Henon-H... https://benchmarks.juliadiffeq.org/html/DynamicalODE/Quadrupole_boson_Hamiltonian_energy_conservation_benchmark.html https://benchmarks.juliadiffeq.org/html/DynamicalODE/Quadrup... As you get outside of Float64 range, the parallelized explicit extrapolation methods seem to do better. This is something we're going to be getting a lot more precise benchmarks in JuliaDiffEq now though, since we have optimized generic implementations of each of the methods and can thus use Float128 and arbitrary precision on all of the methods simultaneously to really figure out the cutoff. But thinking about efficiency and accuracy misses the point of Taylor methods. The Taylor methods have a way of getting rigorous error bounds on the integration (like interval arithmetic, but for the continuous ODE), which is the real reason why they can be useful, with the extra cost of course.
- m4r35n357 7y ago
  Erm, sure I know that name from somewhere! I won't dispute your claims about alternative methods, but I've found it hard to find any open documentation about this stuff, so I am unaware of it myself. Then again, I hereby announce that I am an _amateur_ at this, so I'm not taking criticism personally! In fact one of the reasons I wrote my stuff (FWIW in c and Python) is because I couldn't follow the code in TaylorIntegration.jl ;) My stuff is _really_ simple, and I know _exactly_ how it works.
m4r35n357 7y ago
High order means much less dependence on step size. Automatic (exact) differentiation means no roundoff from finite differences with small step size. They use a very clever and involved code generation approach, I have just hardcoded the recurrences in my implementation (much simpler). https://github.com/m4r35n357/ODE-Playground https://github.com/m4r35n357/ODE-Playground It is not a black box approach like RK4, it depends on the model using a (hardly at all) restricted set of functions. Piecewise definitions are OK though.