public inbox for
 help / color / mirror / Atom feed
* new interface for simulated annealing
@ 2015-07-06 18:33 Matthias Sitte
  2015-07-06 18:49 ` Gerard Jungman
  2015-07-06 20:13 ` Matthias Sitte
  0 siblings, 2 replies; 3+ messages in thread
From: Matthias Sitte @ 2015-07-06 18:33 UTC (permalink / raw)
  To: gsl-discuss

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?



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-07-06 20:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-06 18:33 new interface for simulated annealing Matthias Sitte
2015-07-06 18:49 ` Gerard Jungman
2015-07-06 20:13 ` Matthias Sitte

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).