This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
new interface for simulated annealing
- From: Matthias Sitte <matthias at familie-sitte dot org>
- To: gsl-discuss at sourceware dot org
- Date: Mon, 06 Jul 2015 13:33:14 -0500
- Subject: new interface for simulated annealing
- Authentication-results: sourceware.org; auth=none
Hi all,
I'm currently working on a smaller-size simulated annealing problem. Ideally,
I'd like to use an interface like "ode-initval2", where you can easily select a
different solver while all the dirty work is hidden. Unfortunately, the current
"siman" implementation is rather fixed and doesn't allow what I have in mind.
Expanding it almost immediately breaks the API. So I'm trying to implement a
"new" simulated annealing interface inspired by the "ode-initval2" interface
with separate stepper, control, evolve, and driver objects. It's not yet fully
finished, but I'd like to hear your thoughts on it in general, and how to
proceed if you want to incorporate it into GSL at some point (in terms of
requirements etc).
There's one more question: The "ode-initval2" implementation always takes a
"double y[]" array as input/output. Other method like the Nelder-Mead in
"multimin" (which is one of my other candidate algorithms) work in terms of
"gsl_vector" and "gsl_matrix". I'm a bit confused: What is the preferred GSL way
to deal with this?
Regards,
Matthias