Thanks Olaf, see bellow for comments. On 17 May 2010 11:03, Olaf Till <[email protected]> wrote: > On Mon, May 17, 2010 at 08:43:20AM +0100, Gary wrote: >> I haven't rerun the script as it takes some time to complete, but I >> have attached the raw data from which I generated the spreadsheet. > > The last parameter is computed to be 0, which violates the lower bound > of 1e-30. Constraints (and bounds) are accounted for by leasqr with a > "projection algorithm" --- if a constraint is active and remains > active over the next step, the next parameters are computed to be at > the "border" of the constraint (e.g. exactly at the bound). This > computation was remarkably accurate in my own tests, but I think one > has to live with some inaccuracy. I'd guess that such inaccuracy is > the reason for the above violation.
Is a step the same as an iteration? The 1st iteration of the leasqr algorithm ends around fit function call 103, During the debug run, one parameter that should be +ve and ~10^18 changes in the following way: CALL VALUE 1-102: +ve and ~ 10^-18 then -ve until 116: -1.2025e-19 117: +1.2025e-19 118: +1e-30 119: -1.2025e-19 120-: -ve Is this switching between the sign and being bound and then not bound within a singer iteration consistent with the inaccuracy of the methods for implementing bounds? > The lower bound should be just increased to a "reasonable" value where > small violations can be tolerated. I'm not sure at the moment how > parameter scale affects this problem, but would guess that one should > either increase the lower bound according to the scale of the > respective parameter, or scale the parameters (by applying a factor to > them in the model function) so that their order of magnitude gets > similar. Ok, so small in "small violations" means on an absolute and not relative scale? For info, by using the absolute values of the parameters, the optimisation works well with parameters that are a factor of maybe 10^30 different. I will try scaling them to similar values and check to see if the bound violation still occurs. > Further notes: > > The initial parameters 14, 15, and 16 are outside the lower bound; > leasqr will initially set them to the lower bound with a warning (and > then start optimization). Yes, I checked this and the bounds are respected at the start of the run. > You have set niter = 2, which makes it pretty hopeless to achieve > convergence. Accordingly, kvg == 0 had been returned, which means that > no convergance had been achieved. This was purely to save time. As I said before, a full run takes a long time to complete. > Totally unrelated hint: It makes life easier if the response to a mail > is typed _below_ the text you respond to (avoid "top posting"). Don't > take me wrong for criticizing that :-) , it's better to keep to this > practice. I agree! I'm new to google mail and hadn't noticed that the default is to top post. > Olaf > > ------------------------------------------------------------------------------ > > _______________________________________________ > Octave-dev mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/octave-dev > Perhaps a few additional comments in the function description text, explaining the limitations of the bounds would be useful to others who may encounter the same or similar problems. The following section in particular would seem to benefit from some further explanation: "If the constraints are just bounds, it is suggested to specify them in 'options.bounds' instead, since then some sanity tests are performed, and since the function 'dfdp.m' is guarantied not to violate constraints during determination of the numeric gradient only for those constraints specified as 'bounds'." Thanks for you help Olaf, it has been much appreciated! Gary ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
