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 [email protected] http://lists.gnu.org/mailman/listinfo/help-gsl
