-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor recruitment deviations to log space #514
Conversation
Co-authored-by: iantaylor-NOAA <[email protected]> Co-authored-by: KyleShertzer-NOAA <[email protected]>
changing recruitment deviations to logspace resulted in failing tests in test-fims-estimation. I have compared output from tests to output run from test-fims-estimation on main. All estimated values and negative log-likelihood values are identiical. I suspect tests are failing because gradients are larger with the refactor. |
fixed gradient tests by removing the first log_recruit_dev from calculations as this value was not informing likelihoods. Additionally moved initial logr0 off true value. The log_recruit_dev vector is now of length nyears-1. If this is how we want to constrain this vector moving forward, I will fix the remaining R and C++ tests |
@Andrea Havron - NOAA Federal ***@***.***> This is confusing,
if log_recruit_dev[0] is not informing the likelihood, why would changing
the indexing impact the gradient? It results in an unevaluated branch in
the derivative chain (w+=w*dx => w+=w*0 = w).
…On Mon, Nov 6, 2023 at 3:28 PM Andrea-Havron-NOAA ***@***.***> wrote:
fixed gradient tests by removing the first log_recruit_dev from
calculations as this value was not informing likelihoods. Additionally
moved initial logr0 off true value.
The log_recruit_dev vector is now of length nyears-1. If this is how we
want to constrain this vector moving forward, I will fix the remaining R
and C++ tests
—
Reply to this email directly, view it on GitHub
<#514 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABFUSEG4HS4GYKMS2YXPHHLYDFCAHAVCNFSM6AAAAAA65CLBIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJWGM4DEMZUHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Matthew Supernaw
*Scientific Software Developer*
*National Oceanic and Atmospheric Administration*
*Office Of Science and Technology*
*NOAA Fisheries | *U.S. Department of Commerce
Phone 248 - 396 - 7797
|
@msupernaw, what I said above wasn't exactly correct. log_recruit_dev[0] is being evaluated in the recruitment likelihood, but nothing from population is informing the parameter. log_recruit_dev[0] is being pulled towards 0 as that is the mean of the rec_nll. I think this issue is related to the fact that there isn't a constraint on the log_rec_dev vector. We will be investigating the best way to constrain the log_recruit_devs in M2 (issue #364) and can look into this issue further then. Typically, this vector should be a length of nyears-1, to account for the lose of a degree of freedom in the constraint. |
We decided to add a new index i_dev so it is a bit more clear that this is different from year-1. We also added documentation throughout explaining that the log_recruit_dev did not include the initial term. |
I have merged main into this branch so do not update using rebase |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #514 +/- ##
==========================================
+ Coverage 74.58% 76.10% +1.52%
==========================================
Files 38 37 -1
Lines 2034 1791 -243
Branches 136 0 -136
==========================================
- Hits 1517 1363 -154
+ Misses 476 428 -48
+ Partials 41 0 -41 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this substantial change - at some point during M2 we should revisit the +1 and -1 throughout the indexing since I'm concerned these could lead to user index errors.
What is the feature?
How have you implemented the solution?
Does the PR impact any other area of the project?
How to test this change
Developer pre-PR checklist
devtools::check()
locally and the package compiled and all R tests passed. If there are failing tests, rundevtools::test(filter = "file_name")
(where "test-file_name.R" is the file containing the failing tests) to troubleshoot tests. -->