## digitalmars.D.announce - Package for differential equation solvers

- =?UTF-8?B?RmzDoXZpbw==?= (11/11) Jan 02 Hi folks,
- James Blachly (3/15) Jan 02 Have you talked to Ilya Yaroshenko (9il) ? This might slot in well with
- Kirill (3/3) Jan 03 Great to see someone is bringing d to numeric algorithms.
- AB (50/61) Jan 10 Hi Flavio, thanks for starting this discussion, it is some time

Hi folks, I have started a repository to port Differential equation solver code to D. The goal is to have efficient implementations in D that have a much simpler interface for users than current C, C++, and FORTRAN libraries. Currently is just a couple of solvers quickly whipped together (probably with bugs) as a proof of concept. Please join me to help create this! https://github.com/fccoelho/D-DifferentialEquations Contributors are very, very, VERY MUCH welcome!

Jan 02

On 1/2/21 4:47 AM, Flávio wrote:Hi folks, I have started a repository to port Differential equation solver code to D. The goal is to have efficient implementations in D that have a much simpler interface for users than current C, C++, and FORTRAN libraries. Currently is just a couple of solvers quickly whipped together (probably with bugs) as a proof of concept. Please join me to help create this! https://github.com/fccoelho/D-DifferentialEquations Contributors are very, very, VERY MUCH welcome!Have you talked to Ilya Yaroshenko (9il) ? This might slot in well with libmir.

Jan 02

Great to see someone is bringing d to numeric algorithms. Back in the days https://www.boost.org/doc/libs/1_75_0/libs/numeric/odeint/doc/html/index.html was my favorite library since it is templated.

Jan 03

On Saturday, 2 January 2021 at 09:47:28 UTC, Flávio wrote:Hi folks, I have started a repository to port Differential equation solver code to D. The goal is to have efficient implementations in D that have a much simpler interface for users than current C, C++, and FORTRAN libraries. Currently is just a couple of solvers quickly whipped together (probably with bugs) as a proof of concept. Please join me to help create this! https://github.com/fccoelho/D-DifferentialEquations Contributors are very, very, VERY MUCH welcome!Hi Flavio, thanks for starting this discussion, it is some time that I think D has potential for numeric code, but every time I tried to use it I have found that it lacks some features I want. First, I agree with Kirill that a templated interface is better than one based on real slices. In my experience it is quite useful to - use higher or lower precision types to trade speed for accuracy or vice versa, - use arbitrary precision types or dynamic precision, - use auto differentiation on parameters, - allow matrix(or tensor)-valued equations. It seems to me that an explicit step can cover the full generality by being templated over three types: -the type of time -the type of f(t) Probably it is possible to deduce all types from the signature of f, but that would require a meta-programming expert Example 1: auto explicitEulerStep(fun, time, val)( fun f, time t, time dt, val y) // some constraint magic to check that the following operations are possible: // 1) "t+dt" // 2) "f(t,y)" is a valid call // 3) "f(t,y)" returns a val { return tuple(t+dt, y+dt*f(t,y)); } Note that there is no need to pass additional parameters to f. This is because it can be a delegate (or function literal) and it can contains its own parameters. Example 2: explicitEulerStep( (real t, real y)=>sin(k*t)*y,t, y ); I am a bit less confident about a viable implementation strategy for implicit methods. In this case a solution strategy for the resulting equation is needed. For ease of use a default should be provided, for instance findRoot from std.numeric, but that would not work for vector valued equations and in general the ability to tailor the solver is needed. auto implicitEulerStep(solver, fun, time, val)( fun f, time t, time dt, val y) { return tuple(t+dt, solver.find_root( (val yy)=> yy-y-dt*f(t+dt,yy)) ); } Hopefully it is possible to find a nice solution. Happy new year! AB

Jan 10