help-gsl
[Top][All Lists]

## Re: [Help-gsl] Multidimensional minimization problem

 From: Tuomo Keskitalo Subject: Re: [Help-gsl] Multidimensional minimization problem Date: Tue, 18 Sep 2012 22:18:20 +0300 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0

```Hello,

```
generally speaking, the fminimizer_nmsimplex does not cope well with high dimension problems. In your case it gets stuck, reflecting the worst point from one side to another. Like Rhys said, the improved (and preferred) fminimizer_nmsimplex2 does not get stuck, so in principle you could use it (with high number of iterations, possibly with several restarts of the optimizer). However, these polytope search algorithms are not really efficient for high dimension problems. You would probably do better by using one of the algorithms which utilize derivative information, if you can.
```
BR,
Tuomo

On 09/18/2012 04:03 PM, Rhys Ulerich wrote:

```
```Oops.  This time with the list CCed...

```
```I am running multidimensional minimization along the lines of the examples
in chapter 36.9 of the manual. gsl_multimin_fminimizers seem to converge to
the correct answers when dimension of the problem is low.

e.g. setting VECLEN=10 (see code below) delivers:

```
```converged to minimum at
6606 f() =   0.000 size = 0.000
```
```
However when I raise dimension e.g. to 18 the algorithms seem to get stuck

```
```999999 f() = 237.603 size = 0.000
```
```
I agree that it seems gsl_multimin_fminimizer_nmsimplex probably
should get this one right, but I'm afraid I don't know the guts of the
algorithm.  Printing more precision I see it get stuck in some sort of
a hiccup a la
74915 f() =   238.8119354938235404 size = 0.0000004931914997
74916 f() =   238.8119354938235404 size = 0.0000004941216761
74917 f() =   238.8119354938235404 size = 0.0000004931914997
74918 f() =   238.8119354938235404 size = 0.0000004941216761
74919 f() =   238.8119354938235404 size = 0.0000004931914997
74920 f() =   238.8119354938235404 size = 0.0000004941216761
74921 f() =   238.8119354938235404 size = 0.0000004931914997
74922 f() =   238.8119354938235404 size = 0.0000004941216761
74923 f() =   238.8119354938235404 size = 0.0000004931914997
where you can see the iterates oscillating.  Changing the STEPSIZE
sumply changes where the algorithm gets stuck:
49020 f() =   117.9245273558944547 size = 0.0000002658725425
49021 f() =   117.9245273558944547 size = 0.0000002659099457
49022 f() =   117.9245273558944547 size = 0.0000002658725425
49023 f() =   117.9245273558944547 size = 0.0000002659099457
49024 f() =   117.9245273558944547 size = 0.0000002658725425
49025 f() =   117.9245273558944547 size = 0.0000002659099457
49026 f() =   117.9245273558944547 size = 0.0000002658725425
49027 f() =   117.9245273558944547 size = 0.0000002659099457
49028 f() =   117.9245273558944547 size = 0.0000002658725425
49029 f() =   117.9245273558944547 size = 0.0000002659099457
49030 f() =   117.9245273558944547 size = 0.0000002658725425

I do see gsl_multimin_fminimizer_nmsimplex2 getting the VECLEN 18
problem to f() = 0.50421136 given TOLERANCE 2e-15 in about 1.5M
iterations.  I haven't checked if it similarly gets stuck with
oscillating iterates.

I'd be interested to hear if you track down the source of these
oscillating iterates.

To be fair, you're cheating when you say it's a simple problem.  :)
You intuitively know the derivatives but neither
gsl_multimin_fminimizer_nmsimplex nor
gsl_multimin_fminimizer_nmsimplex2 does.

Hope that helps,
Rhys

```
```

--