[ADMB Users] Non-matching analytic and numeric derivatives
jefflaake at gmail.com
Mon Oct 20 14:05:34 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.
> init_number kkludge(2)
> ... (calls function to compute f)
> ... (in function to compute f)
> double myeps=1.e-12;
> if (current_phase()==1)
> f-= log(pch+myeps); // sum
> log-likelihood log(pr(ch))
> 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.
> regards --jeff
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users