Re: [Bug-gsl] Possible bug (or room for improvement) in gsl_mmin_simp2

[Neil Stewart]

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.