On 27 May 2010 15:33, Olaf Till <[email protected]> wrote: > On Thu, May 27, 2010 at 09:59:48AM +0100, Gary wrote: >> On 20 May 2010 07:05, Olaf Till <[email protected]> wrote: >> > On Tue, May 18, 2010 at 01:09:07PM +0200, Olaf Till wrote: >> >> dfdp does not cope well with the mentioned inaccuracy in bounds, I'll >> >> try to fix that soon. It's probably also better to correct the >> >> parameters to the bounds after each step, but only if no constraints >> >> except bounds are specified. >> > >> > Both done. You might want to test the new version (in SVN). >> > >> > Olaf >> > >> >> Thanks Olaf, >> >> Sorry for taking so long to get back to you - I've not had much time >> to work on this recently. >> >> In my test run, the svn version (1.0.13) respects bounds for all calls >> to the fitting function. In the same run with optim-1.0.12, the bounds >> were violated and no further optimisation could be done. However, when >> I worked around the violation of bounds by passing the absolute values >> of the parameters to the external program, optimisation continued and >> convergence was reached. This no longer happens in 1.0.13; when the >> bound is set, the parameter remains at the bound value. >> >> I believe it's possible that this is an issue specific to my problem, >> but I just wanted to let you know. >> >> I haven't tried scaling the parameters yet, but plan to do so. >> >> Gary >> > > Thank you for the information. But in the case this is really a bug, > it is sad that you can't send me the "fit function" for > verification. I cannot make changes merely "from hear-say". > > An erroneus "trapping" at bounds can be expected if bounds are simply > enforced by cutting parameters back to bounds. But I would have > thought that the projection algorithm is resistant to this phenomenon; > this was also indicated by my own tests. I would not expect that a > mere correction of inaccuracy at the bounds could lead to the above > "trapping". > > An explanation for your results might be the existance of different > local minima (or just regions with no appreciable improvement); one > region at high (absolute) parameter values, another region (or > minimum) at the bounds. > > Olaf > > ------------------------------------------------------------------------------ > > _______________________________________________ > Octave-dev mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/octave-dev >
I have been able to let my test runs continue of over the last few days and have some good news for you, Olaf: after a parameter becomes trapped at the bound, it stays there for several iterations, but then slowly recovers towards the correct value, so I don't think there is a bug in the code! When the projection algorithm breaks the bounds in the current version, or is trapped at the bounds in the svn version, the fit becomes much, much worse. I think the slow improvement is probably consistent with being in a region with no appreciable improvement, as you say, because the parameter is very far from the optimum value. If I understand the help text correctly, using 'options.max_fract_change' should help avoid the inherent inaccuracy of the prediction algorithm causing problems. I've tried scaling the parameters, so that all values of 'pin' are close to 1, but this produced very similar results to runs without parameter scaling, where there are factors of 1e40 between the largest and smallest parameters under optimisation, so I don't think this has been an issue. Thanks for you help, Gary ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
