# Fmincon does not even try other points other than initial x0

33 Ansichten (letzte 30 Tage)
Conrado Neto am 10 Jun. 2020
Kommentiert: Conrado Neto am 11 Jun. 2020
I am running into a problem I cannot understand,
I have an objective function that uses some external .exe programs to obtain its value, thus I believe a complex one
I ask matlab to provide the x values being used in the objective function at each iteration, and for some reason, fmincon always uses the exact same values of x0 several times, and then it says it found that the initial point is the local optimal.
wasn't fmincon supposed to try other values of x before getting to that final result? what could I be doing wrong?
• I tried the same code using ga and it does try different x and gives different results at each iteration, for that reason I believe the code I used for fmincon should not have any basic mistake (such as the objective function being constant).
thanks,
##### 0 Kommentare-2 ältere Kommentare anzeigen-2 ältere Kommentare ausblenden

Melden Sie sich an, um zu kommentieren.

### Akzeptierte Antwort

Matt J am 11 Jun. 2020
Bearbeitet: Matt J am 11 Jun. 2020
wasn't fmincon supposed to try other values of x before getting to that final result?
No, fmincon is a gradient-based solver (unlike ga) so if x0 is feasible and the gradient there is already zero, then fmincon has no reason to try other points. Often this happens because you have discretization operations like round() or ceil() in your objective function, which make it locally flat almost everwhere. For example, this 1D function is locally flat at all points except the integers:
fun=@(x) floor(x);
opts=optimoptions('fmincon','Display','none');
fplot(fun,[0,5]); xlabel 'x', ylabel 'Objective'
and therefore almost any initial point you choose will be locally optimal,
>> fmincon(fun,1.5,[],[],[],[],0,5,[],opts)
ans =
1.5000
>> fmincon(fun,2.7,[],[],[],[],0,5,[],opts)
ans =
2.7000
>> fmincon(fun,3.99,[],[],[],[],0,5,[],opts)
ans =
3.9900
##### 4 Kommentare2 ältere Kommentare anzeigen2 ältere Kommentare ausblenden
Matt J am 11 Jun. 2020
Yes, some people manage to address the problem by increasing the DiffMinChange parameter. That way, the finite differencing operations used to calculate gradients will take larger steps. However, I think it is better to trace the cause of the local plateaus in the objective function and remove them.
Conrado Neto am 11 Jun. 2020
Thanks again,
the problem is that due to the nature of the problem that I solving, a small change in x surely wont represent the actual change in the objective function. the change in the objective function would be a result of small "errors" in the calculation
in my analysis the change in x is only representative when it is significant.
so it does make sense to change the DiffMinChange parameter.
as a last question, do you happen to have any reference about solving a problem of this nature?

Melden Sie sich an, um zu kommentieren.

### Weitere Antworten (1)

Alan Weiss am 11 Jun. 2020
Alan Weiss
MATLAB mathematical toolbox documentation
##### 1 Kommentar-1 ältere Kommentare anzeigen-1 ältere Kommentare ausblenden
Conrado Neto am 11 Jun. 2020
Thanks Alan

Melden Sie sich an, um zu kommentieren.

### Kategorien

Mehr zu Solver Outputs and Iterative Display finden Sie in Help Center und File Exchange

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by