608 variable vector tests documentation

[Andrea-Havron-NOAA]

What is the feature?

• Addresses Issues [Developer Issue]: Add documentation to rcpp_interface_base on dev branch #608 and [Developer Issue]: complete tests in test-unit-rcpp-interface-base-variable-vector #609

How have you implemented the solution?

• Condensed operator.R file and added S4 documentation
• Documented Parameter and ParameterVector classes in rcpp_interface_base and made requested name changes
• Converted remaining tests in test-unit-rcpp-interface-base-variable-vector to testthat format
• Ran devtools::document() locally to generate S4 class documentation and modify the NAMESPACE
• Ran devtools::check() locally, there are a couple warnings related to S4 documentation that will be filed as a new issue.

Does the PR impact any other area of the project?

How to test this change

Developer pre-PR checklist

• I relied on GitHub actions to 🧪 things for me while I sat on the 🛋️.

[x] Ran devtools::document() locally and pushed changes to this remote feature branch

[x] Ran devtools::check() locally and the package compiled and all R tests passed. If there are failing tests, run devtools::test(filter = "file_name") (where "test-file_name.R" is the file containing the failing tests) to troubleshoot tests.

[github-actions]

Instructions for code reviewer

Hello reviewer, thanks for taking the time to review this PR!

• Please use this checklist during your review, checking off items that you have verified are complete!
• For PRs that don't make changes to code (e.g., changes to README.md or Github actions workflows), feel free to skip over items on the checklist that are not relevant. Remember it is still important to do a thorough review.
• Then, comment on the pull request with your review indicating where you have questions or changes need to be made before merging.
• Remember to review every line of code you’ve been asked to review, look at the context, make sure you’re improving code health, and compliment developers on good things that they do.
• PR reviews are a great way to learn, so feel free to share your tips and tricks. However, for optional changes (i.e., not required for merging), please include nit: (for nitpicking) before making the suggestion. For example, nit: I prefer using a data.frame() instead of a matrix because...
• Engage with the developer when they respond to comments and check off additional boxes as they become complete so the PR can be merged in when all the tasks are fulfilled. Make it clear when this has been reached by commenting on the PR with something like This PR is now ready to be merged, no changes needed.

Checklist

• The PR is requested to be merged into the appropriate branch (typically main)
• The code is well-designed.
• The functionality is good for the users of the code.
• Any User Interface changes are sensible and look good.
• The code isn’t more complex than it needs to be.
• Code coverage remains high, indicating the new code is tested.
• The developer used clear names for everything.
• Comments are clear and useful, and mostly explain why instead of what.
• Code is appropriately documented (doxygen and roxygen).

[msupernaw]

@chris Legault - NOAA Federal ***@***.***> Each element of the vector is independent and can be set to estimated or not. Each element is a Parameter with the same fields and methods. So, you can fix one element in a selectivity model that uses a vector and estimate the rest to make the model identifiable.

…

On Wed, Jun 12, 2024 at 8:32 AM Chris Legault ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In inst/include/interface/rcpp/rcpp_interface.hpp <#623 (comment)>: > Rcpp::class_<ParameterVector>("ParameterVector") .constructor() .constructor<size_t>() .constructor<Rcpp::NumericVector, size_t>() - .field("data", &ParameterVector::storage_m) - .method("at", &ParameterVector::at) - .method("size", &ParameterVector::size) - .method("resize", &ParameterVector::resize) - .method("set_all_estimable", &ParameterVector::set_all_estimable) - .method("set_all_random", &ParameterVector::set_all_random) - .method("fill", &ParameterVector::fill); + .field("data", &ParameterVector::storage_m, "list where each element is a Parameter class") + .method("at", &ParameterVector::at, "returns a Parameter at the indicated position given th eindex argument") + .method("size", &ParameterVector::size, "returns the size of the Parameter Vector") + .method("resize", &ParameterVector::resize, "resizes the Parameter Vector given the provided length argument") + .method("set_all_estimable", &ParameterVector::set_all_estimable, "sets all Parameters within vector as estimable") Does this imply that parameter vectors can only be all estimated or none estimated? I can think of some situations where I would want to estimate some but not all of a parameter vector. For example, if selectivity is estimated by age, and a parameter vector is used for this selectivity, then one of the ages needs to be fixed for the model to be identifiable. Sorry if I'm overinterpreting this method to imply something that is not true. — Reply to this email directly, view it on GitHub <#623 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFUSEGRN55BDYR6YC6YCRLZHA5UDAVCNFSM6AAAAABJFIXR5GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCMJSHA3TOOJQGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Matthew Supernaw Mathematical Statistician *National Oceanic and Atmospheric Administration* *Office Of Science and Technology* *NOAA Fisheries | *U.S. Department of Commerce Phone 248 - 396 - 7797