[ADMB Users] Non-matching analytic and numeric derivatives
jefflaake at gmail.com
Mon Oct 20 08:36:24 PDT 2014
I want to follow up on this subject to summarize further discussions.
The problem I was having was NOT the choice of the increment to avoid
log(0). Possibly Dave ran into this because I forgot to include the
.pin file when I sent him the files. The problem was due to having
-gbs too small. I'm guessing that if -gbs is too small the code can't
properly compute the analytic derivatives and the code fails to make
any progress, Once I increased -gbs the code worked properly and
converged. That said, what Dave stated here isn't exactly what he
did. You have to be careful with the size of the epsilon you add to
avoid log(0). I followed literally what he said here and he and I came
up with substantially different log-likelihood values (-74 units).
You need to use a value that is very small relative to the actual
quantity. In my case they are probabilities that can be very small
because it is a 27 year capture history.
As it turns out, Dave started with 1e-8 and then switched to 1e-12 in
the second phase. He implemented that by creating a dummy parameter
(kkludge) that simply forced a second phase but which had value 0 and
didn't affect the resulting value. Without showing entire tpl file,
this shows the changes he made which added kkludge (set to 0 in pin)
and shows how eps was changed at second phase.
... (calls function to compute f)
... (in function to compute f)
f-= log(pch+myeps); // sum
Note that currently -gbs is limited to about 2gb on windows machines
even for the 64 bit version. This is something that Johnoel is
working on presently.
On Fri, Oct 10, 2014 at 10:45 AM, dave fournier <davef at otter-rsch.com> wrote:
> On 10/09/2014 07:32 AM, Jeff Laake wrote:
> This might be of interest to others so I cc's it to the list.
> In your code for the log-likelihood you have the line.
> f-= log(pch+0.000000000000000000000001);
> Now I figured that 0.000000000000000000000001 might be too small.
> What would happen is that is pch is zero you will get derivatives on the
> order of
> 1.0/ (0.000000000000000000000001)
> and this could make the model numerically unstable at least during the
> initial fitting stage.
> I modified this to
> f-= log(pch+1.e-8);
> and ran the model for a while and then used the values as initial values to
> run the
> model with your original code. It converged easily.
> There is nothing magical about 1.e-8. For some models you might need
> something like 1.e-4 to start.
>> Per Johnoel's request I forwarded a zip containing an example in which
>> the numeric and analytic derivatives don't match when I use -dd. The
>> code fails because it thinks it should move but can't make any
>> progress because it is at the min.
More information about the Users