Re: [Gretl-devel] testcases and pet projects
Am 06.07.2009 14:24, Riccardo (Jack) Lucchetti schrieb:
>>
>> is that, in normal circumstances, we want to avoid jumping from one
>> place to another if the jump doesn't yield a *significant*
>> improvement in the objective function.
>>
> I've checked with BFGS_DEBUG on and it seems that d is always
> negative. So if i understand correctly, gretl doesn't look for a
> significant improvement, but is happy even if f decreased by abs(d)
So if that's true (and it looks like it, no?) then I'm wondering whether
(a) the reasoning about the "significant improvement" is still valid and
it really is a shame that gretl didn't do it all along, or
(b) if gretl's performance with that bug over the last years shows that
the reasoning really doesn't apply, it's working ok without.
I am really asking, not suggesting. Also, could it be that some other
tricks that gretl uses ("simulated annealing" etc.?) have made the d bug
less relevant? Or would this bug mean that some of the users' more
difficult optimization problems simply have gone wrong?
Hm, you got me thinking on this one. In fact, I suspect that this is a
bug that's been there for more than 2 years. Allin, please check if what
I'm saying makes sense to you. Our original BFGS implementation was
ripped from somewhere else (I believe it was R, but I may be wrong) and
it was conceived as a _minimiser_ rather than a _maximiser_. Then, we
decided to flip the sign, so to speak: you can see this by comparing
versions 1.181 and 1.182 of lib/src/nls.c, where BFGS was at the time.
The "d" check, however, stayed the same. So, if my analysis is right,
the "right" patch would be
Index: lib/src/gretl_bfgs.c
===================================================================
RCS file: /cvsroot/gretl/gretl/lib/src/gretl_bfgs.c,v
retrieving revision 1.7
diff -u -r1.7 gretl_bfgs.c
--- lib/src/gretl_bfgs.c 6 Jul 2009 04:24:02 -0000 1.7
+++ lib/src/gretl_bfgs.c 6 Jul 2009 12:14:13 -0000
@@ -543,7 +543,7 @@
}
if (ndelta > 0) {
f = cfunc(b, data);
- d = sumgrad * steplen * acctol;
+ d = - sumgrad * steplen * acctol;
fcount++;
crit_ok = !na(f) && (f >= fmax + d);
#if BFGS_DEBUG
I still don't know the code context, but if a sign needs to be flipped,
are you sure it shouldn't come earlier, in one of the ingredients to d?
Maybe in sumgrad instead? I mean if it's a maximiser then my gut feeling
is that the problem and the signs should be defined such that ad-hoc
flippings of signs later on would not be necessary.
However, I believe my earlier argument about the matrix H is still
correct at least in part, so we may want to change the above to
d = (iter>0) ? -sumgrad * steplen * acctol : 0;
although in this case, we'd make the algorithm more lenient, not
stricter (which may be undesirable).
if given the optimal values already as inputs, which of the two versions
would also spit them out as the result of the optimization? (it almost
looks as if it could be a problem if d is not set to 0, but I'm not
sure, so asking again.)
Chris' test script runs fine with the above patch applied. I also ran a
few other tests and nothing wrong appeared. Before committing, though,
I'd like to hear Allin's opinion.
Maybe I'm wrong, but this looks like a sensitive issue. Imagine what
would happen if many users get different results from their existing
scripts after upgrading gretl. Of course the bug should be fixed, but I
believe the implications should be thought through well, also in order
to communicate the issue in a transparent und understandable way.
thanks,
sven