Re: [Help-gsl] nmsimplex2 gets stuck when nmsimplex doesn't

[awsteiner]

FYI Neil and all, see also this thread at bug-gsl:

http://lists.gnu.org/archive/html/bug-gsl/2009-07/msg00028.html

On Jul 28, 2009 7:59am, Neil Stewart <address@hidden> wrote:
> I'm having trouble with the new Nelder Mead simplex algorithm and I think  
> I

> may have found a bug. The algorithm initially crawls down hill  
> successfully

> for several hundred iterations, but them seems to collapse and get stuck.



> Below are the vertices for one iteration of the stuck simplex. The problem

> has 14 parameters (the first 14 columns; the final column is the function

> value being minimised). The 16 rows are the 16 times the to-be-minimised

> function was called during a single gsl_multimin_fminimizer_iterate().

> Notice how, after the first two rows, all of the remaining rows are

> identical. The simplex has collapsed to a single point.



> The algorithm will run indefinitely, repeating these vertices over and  
> over.

> Different random starting points nearly all end up here, or in another

> similar pattern. Restarting the algorithm from here with a bigger simplex

> size kicks it on, but it collapses again at a different point.



> 0.03242 0.30522 0.63573 0.90886 0.00071 0.00181 0.00612 0.03337 0.12715  
> 0.00038 0.04802 0.16050 0.41929 0.62331 5.34309

> 0.03269 0.29779 0.62830 0.90143 0.00077 0.00194 0.00626 0.03461 0.12125  
> 0.00039 0.04927 0.15408 0.41190 0.61599 5.31868

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702

> 0.03278 0.29531 0.62582 0.89895 0.00079 0.00198 0.00631 0.03503 0.11929  
> 0.00040 0.04969 0.15194 0.40944 0.61355 5.31702



> (I've omitted some decimal places, but the last 14 rows are identical to  
> at

> least 18 decimal places.)



> I'm using the new gsl_multimin_fminimizer_nmsimplex2 algorithm. Switching

> back to the original gsl_multimin_fminimizer_nmsimplex algorithm (notice  
> the

> missing 2 at the end) fixes the problem. The original algorithm always

> converges on the same minimum, even when started from many different

> starting points, which is nice.



> The collapse of the simplex into a single point seems like a bug in

> gsl_multimin_fminimizer_nmsimplex2. Any comments most welcome.







> _______________________________________________

> Help-gsl mailing list

> address@hidden

> http://lists.gnu.org/mailman/listinfo/help-gsl