Very important.
This is true for virtually ANY optimizer. Think of an optimizer as a blind person, put down on the face of the earth, then tasked with finding the lowest point on the surface of the earth. Worse, since this person is blind, they can use only a cane to determine which direction to move in, purely locally.
So, if everywhere the person looks in the immediate vicinity seems to point upwards, then they are done. The process will terminate, because it appears they have found a minimizer. Is it a global minimizer? Who knows? If every direction points uphill from that spot, then there is no place to go.
So, given these constraints, would you expect the person to find a deep ocean trench, in fact, the deepest such ocean trench, if they were started out in the middle of the Mongolian Steppes? Odds are, they will get stuck in some small, local valley, a little depression, or in some tiny little pond. Start someone out near the Dead Sea, and they will end up in the bottom of the Dead Sea. (I hope they can use scuba gear.) But if you do start them out near the Dead Sea, it is pretty certain they will NEVER find their way to the Marianas trench.
Can you expect ANY optimizer to be able to magically know the entire shape of a surface that is only known as a complete "black box"? A "black box" is a term used to describe a general process that you send parameters into, and then get output. So a general function is a black box. MATLAB knows nothing about what you do inside that black box, just that some output is generated for any set of inputs. Optimizers have some constraints/requirements on the set of functions they will handles. In general, continuity, differentiability, etc. are all required, or at least valuable aspects of the black boxes they will handle as objective functions.
Some functions have only a single local minimum. For example, given the function
fun = @(x) (x-1).^2;
does it matter where you start looking? OF COURSE NOT! There is only one minimum on the real line, at x==1. You can start at x==0, or at x=1e6. Eventually, any place that you start (within reason: don't start at x=1e10000, as that will overflow the dynamic range of a double precision number) then you will find the solution. Of course, some starting points will take longer than others to arrive at the solution.
Having said all of that, fminsearch is not terrible. It is capable of escaping a local minimum. Consider this example:
fun = @(x) 2*sin(x) + abs(x);
ezplot(fun,[-50,50])
grid on
One might think that IF you started the tool at x=100, that it MUST fail, stopping around x=45.
opts.Display = 'iter';
[xmin,fmin] = fminsearch(fun,50,opts)
Iteration Func-count min f(x) Procedure
0 1 49.4753
1 2 49.4753 initial simplex
2 4 46.7018 expand
3 6 34.1436 expand
4 8 16.3006 expand
5 10 6.91785 reflect
6 12 3.08215 contract inside
7 14 0 contract inside
8 17 0 shrink
9 19 -0.647969 contract outside
10 21 -0.647969 contract inside
11 23 -0.674662 contract inside
12 25 -0.68296 contract inside
13 27 -0.683995 contract inside
14 29 -0.684805 contract inside
15 31 -0.684805 contract inside
16 33 -0.684849 contract inside
17 35 -0.684849 contract inside
18 37 -0.684853 contract inside
19 39 -0.684853 contract inside
20 41 -0.684853 contract inside
21 43 -0.684853 contract inside
22 45 -0.684853 contract inside
23 47 -0.684853 contract inside
Optimization terminated:
the current x satisfies the termination criteria using OPTIONS.TolX of 1.000000e-04
and F(X) satisfies the convergence criteria using OPTIONS.TolFun of 1.000000e-04
xmin =
-1.0472
fmin =
-0.68485
As you can see, it found the local min just under x=50. Then, before giving up, it tried taking a larger view, just in case there were other solutions. So fminsearch did surprisingly well here, finding the globally minimum value at x=-1.0472. Don't expect it to always succeed, with ANY starting values, on ANY function.
