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

=?UTF-8?B?RmzDoXZpbw==?= <fccoelho gmail.com> writes:

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!

James Blachly <james.blachly gmail.com> writes:

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.

Kirill <bribeme gmail.com> writes:

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.

AB <a b.c> writes:

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