Werner Exinger wrote:
The center is not allways the best start value and as already written, minimize will give you one local min, but not necessarily the absolute min. I guess we could also find examples where minimize would find a local min but another local min is smaller.
EDIT: Found an example and integrated it in the pic above. ;-)
You could try a couple of start values at small distance, but then we are at brute force again.
Well, sure, the limitations of standard minimization routines are well known. Implementing a multistart version would be easy, and would find the global minima in your examples. And a multistart version of an efficient minimization algorithm is not what I would call "brute force". Your algorithm assumes that the global minimum is not so narrow compared to the range of the function to be searched that 10^4 steps will not miss it. There's no guarantee of that though. In fact, because you do not search within each of your steps, it's possible you could pick the wrong increment to pass to the next recursive call (imagine the global minimum is in increment 1, but the start of increment 1 happens to be larger than the start of increment 2. Then, unless I misread what you are doing, increment 2 will be passed to the next call in the recursion).
BTW, any special reson for that special definition of RApply? Wouldn't it be OK the way Tom has done?:
At one point I couldn't get it to work any other way. Then at a later point I couldn't get it to work anyway, unless I changed the order of the arguments. It seems that doing so also fixed the earlier problem, so you can actually just have f(x) on the RHS.
The order of the arguments when turning minimize into a function are a very strange thing. Its not only that the variable which should be varied has to be the first, also the order of the other arguments matters:
That is for sure. Is seems that in the case of RApply the first argument must be x, the second argument must be f (that's what I changed to fix the problems noted above). The other arguments can be in any order, but the order must match the order in the function definition that terminates the solve block. It's as though they are being passed by order, rather than by name.
BTW, are you going to post a worksheet with your "nasty" cases in it, or are you hoping I will retype everything ?