multidimensional minimization is missing

[BlackEdder]

SciD doesn't have any build in multidimensional minimization routines, which I (and probably others) could use. Because of this I recently wrote a library implementing differential evolution (BlackEdder/minimized). The API of this library is a bit simplistic, but it works. Would it be an idea to incorporate this into SciD? Maybe we should define a general interface for all minimization routines and have my library as one of the implementations?

interface Minimization(RANGE)
{
  RANGE minimize(size_t maxIterations); // Perform minimization
  void setFunction(double delegate(RANGE parameters) ; // Function to minimize
}

[jmh530]

I think there is a lot of value in getting D's optimization routines in line with what is available in other languages. I am a fan of NLopt, but I don't think I have the knowledge to get it working in D.

[kyllingstad]

Sorry for not replying to this earlier!

It would indeed be very nice to have optimisation routines in SciD. And if there are several, it certainly makes sense for them to have the same API, so they are interchangeable. (I'm not sure to what extent that is possible, though. The API for a genetic algorithm is likely to be very different from that for a conjugate gradient algorithm, for example. But it may be possible to define some broad classes of algorithms.)

I'm not sold on the idea of using interfaces and classes like you do, though, because it makes the user pay the price of polymorphic types (indirect function calls, heap allocation, etc.) when polymorphism isn't actually used for anything. I'm a much bigger fan of Phobos-style static interfaces (cf. ranges, containers, RNGs, the upcoming allocators, etc.), which provide max power and performance with no limitations. (If you need polymorphism, it is always possible to create wrappers à la std.range.interfaces.)

[Laeeth]

Nelson-Mead simplex is here, but license (requiring copyright notice display) may be a problem:
https://github.com/Laeeth/d_simplex.git

It works for me, but it's by no means rigorously tested.

It's hard to design an API from top down unless you already are intimately familiar with the nitty gritty of what each will require. It might be worth creating an experimental branch and starting to write implementations there, refine them, and then refactor out later.

Of course you can start by deciding to replicate everything another project does. But it would be a shame to let a grand goal detract from filling in functionality step by step. I am sure many people must have decent implementations squirreled away so if you start to show momentum maybe others will contribute.