Re: NMinimize Method suboptions

*To*: mathgroup at smc.vnet.net*Subject*: [mg124156] Re: NMinimize Method suboptions*From*: "Oleksandr Rasputinov" <oleksandr_rasputinov at hmamail.com>*Date*: Wed, 11 Jan 2012 04:24:00 -0500 (EST)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*References*: <op.v7v2htwiqcgwdu@core2.lan>

It seems that after some investigation I am in a position to answer my own questions, so I am following up my earlier message in case anyone is interested. On Tue, 10 Jan 2012 22:09:19 -0000, Oleksandr Rasputinov <oleksandr_rasputinov at hmamail.com> wrote: > 1. We know that some possible values for the "PostProcess" option are > "KKT", "InteriorPoint", and FindMinimum (with the undocumented Method > suboption giving access to a rather wide range of possibilities). Are > there any others? No. (Except Automatic, which means either "KKT" or "InteriorPoint", or both, in either order, depending on the value of Optimization`NMinimizeDump`$PostprocessOrder.) > And is there any difference between the option values "InteriorPoint" > and {FindMinimum, Method -> "InteriorPoint"}? Different code paths are followed in setting up the minimization, but the same core algorithm is used in both cases. > 2. For the "DifferentialEvolution" method, the documentation states that > recombination is according to Storn and Price's rand/1 scheme. Are any > other schemes implemented? No. Actually even the rand/1 implementation is not done "correctly" (i.e. per the description given by Storn and Price) as the vectors chosen for recombination are picked completely at random, whereas strictly speaking differential evolution requires them to be mutually different as well as different from the base vector (i.e. the one they compete against in the selection tournament). The difference will not matter for a large enough number of search points, but may lead to misconvergence in some cases. Also, the documentation states that differential evolution is computationally intensive, which (as the algorithm is very simple and can be expressed efficiently in terms of array operations) could be taken to refer to the fact that it requires a large number of function evaluations compared to local search methods. However, finding on closer inspection that the implementation is done in an (in my opinion, inappropriate) procedural style and with little attention to efficiency, I now suspect that this is the real reason for its relatively poor performance. This is unfortunate given the strong potential of differential evolution for heavy-duty minimization problems, but perhaps it will be addressed in the future.