I can also confirm that nmsimplex2 is failing where nmsimplex succeeds. I've used Andrew's example and printed parameters and return value of the spring function each time it is called (5 times per iteration). Just as in my own example, the simplex seems to collapse. After the first two evaluations, each subsequent evaluation is for an identical point (this is true for my 14 parameter problem too).
iter = 597 1.000000 0.000000 22.991149 spring:1.507330 1.730067 22.054549 27752466.750698 spring:1.126833 0.432517 22.756999 1927.313000 spring:1.000000 0.000000 22.991149 100.441476 spring:1.000000 0.000000 22.991149 100.441476 spring:1.000000 0.000000 22.991149 100.441476 iter = 598 1.000000 0.000000 22.991149 spring:1.507330 1.730067 22.054549 27752466.750698 spring:1.126833 0.432517 22.756999 1927.313000 spring:1.000000 0.000000 22.991149 100.441476 spring:1.000000 0.000000 22.991149 100.441476 spring:1.000000 0.000000 22.991149 100.441476 iter = 599 1.000000 0.000000 22.991149 spring:1.507330 1.730067 22.054549 27752466.750698 spring:1.126833 0.432517 22.756999 1927.313000 spring:1.000000 0.000000 22.991149 100.441476 spring:1.000000 0.000000 22.991149 100.441476 spring:1.000000 0.000000 22.991149 100.441476 iter = 600 1.000000 0.000000 22.991149 A bit of debugging shows that, once the simplex is stuck, nmsimplex_iterate is trying to reflect the highest value point and failing, and is trying a one-dimensional contraction and failing. I'm afraid I don't understand the algorithm well enough to work out why this is bad, and I don't understand why the simplex is collapsing in the first place. Best, Neil. _______________________________________________ Bug-gsl mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gsl
