[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] siman: fixed vs variable configurations

From: John Gehman
Subject: Re: [Help-gsl] siman: fixed vs variable configurations
Date: Thu, 27 Apr 2006 17:47:26 +1000

Thanks, Brian -- that was a bit silly of me -- I neglected to spot the detail in the travelling salesman problem that would have led me to that.

And I will be happy to be embarrassed again by an easy answer to that which has me stumped now that I'm a bit further down the track. I'm still learning how to control the behaviour of the solver and annealing, but ...

My gsl_siman_Efunc_t receives the void * argument which refers to my data struct, a component of which is the gsl_vector which holds the (17) values that I want to search for/optimize. The optimum values provide for the best fit to data, and it is the rmsd between the data and fit which I return as "Energy". I also set the "double rmsd" component of the data struct to this same value.

As the temperature cools, a params->iters_fixed_T number of different configurations are tried. The configuration corresponding to the minimum energy (rmsd) at each temperature is written to the original input struct. However the Ef(x) output associated with the gsl_siman_print_t function prints the minimum energy (rmsd) found thus far, at any temperature.

As if having hit a local minimum, after the temperature at which this minimum energy is found, the energy bounces back up again, but then never comes back down to this or any lower energy. But still the Ef (x) value persists to report the apparently globally minimum energy value. Oddly, a check of ((struct mysystem *) xp )->rmsd reports this same value.

When the minimum temperature is reached, mysystem contains the configuration of sought-values only for the minimal energy of the last temperature run, not the configuration corresponding to the globally minimum value, but the ((struct mysystem *) xp )->rmsd *does* reflect the globally minimum value, as above.

If I rerun the same function as referenced for the gsl_siman_Efunc_t, the latest values are used and the (struct mysystem *) xp )->rmsd value *does* change to a correctly corresponding elevated value.

I've been hammering at this for ages now, do you reckon I've done something stupid, or is there perhaps some mixup in the siman code that could explain this?


On 25/04/2006, at 5:07 AM, Brian Gough wrote:

The size parameter should then be sizeof(struct mysystem).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]