Closes #2513 accept_ms: accept ms as input unit for derive_param_qtc()

[bundfussr]

Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.

Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main branch until you have checked off each task.

• Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
• Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
• If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
• Review the Cheat Sheet. Make any required updates to it by editing the file inst/cheatsheet/admiral_cheatsheet.pptx and re-upload a PDF and a PNG version of it to the same folder. (The PNG version can be created by taking a screenshot of the PDF version.)
• Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Address any updates needed for vignettes and/or templates
• Update NEWS.md under the header # admiral (development version) if the changes pertain to a user-facing function (i.e. it has an @export tag) or documentation aimed at users (rather than developers). A Developer Notes section is available in NEWS.md for tracking developer-facing issues.
• Build admiral site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.
• Address or fix all lintr warnings and errors - lintr::lint_package()
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue in the Development Section on the right hand side.
• Address all merge conflicts and resolve appropriately
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[bundfussr]

The failing R-CMD checks will pass once pharmaverse/admiraldev#468 is merged.

[yurovska]

Just a super minor comment regarding the order of "ms" and "msec". I think "ms" should go first everywhere in the documentation as this is the standard unit now. Otherwise I'm happy with the changes.

[bms63]

Should we have a test for differing units? or is that already covered and just not seeing it??

[bundfussr]

Test 1 tests ms and Test 2 msec.

[bms63]

sorry i meant the tests units are ms and msec in the same the dataset. i have seen this happen a few times over the years where units from different sites differ and are not caught until way later.

[bundfussr]

The unit must be unique within a parameter. This is also checked by assert_unit(). We test it in the unit tests for assert_unit(). I'm not sure if we need to test it for derive_param_qtc(). Then we would need to test other bad inputs like a wrong unit as well. Usually we don't do this.

[bms63]

If you feel confident that this would be caught, then all is good for me.

[bms63]

@bundfussr what do you think about splitting out the functions into separate files? having everything in ad_adeg.R has always irked me a bit.

We can make this a good first issue and have someone new do this and not a priority

...we only do this type of organization for this and the advs_params.

[bundfussr]

@bundfussr what do you think about splitting out the functions into separate files? having everything in ad_adeg.R has always irked me a bit.

We can make this a good first issue and have someone new do this and not a priority

...we only do this type of organization for this and the advs_params.

Yes, we could do this but I would split by endpoint and not by function. For example, I would keep derive_param_qtc() and compute_qtc() in the same file.

By the way, I would like to split assertions.R and test-assertions.R in admiraldev. They have well over 1000 lines. Should I make a proposal how to split them for the next developer meeting?

[bms63]

@bundfussr what do you think about splitting out the functions into separate files? having everything in ad_adeg.R has always irked me a bit.
We can make this a good first issue and have someone new do this and not a priority
...we only do this type of organization for this and the advs_params.

Yes, we could do this but I would split by endpoint and not by function. For example, I would keep derive_param_qtc() and compute_qtc() in the same file.

By the way, I would like to split assertions.R and test-assertions.R in admiraldev. They have well over 1000 lines. Should I make a proposal how to split them for the next developer meeting?

YES PLEASE!! LOVE IT ALL!!!!!!

[github-actions]

Package	Line Rate	Health
admiral	97%	✔
Summary	97% (4952 / 5114)	✔

[bms63]

@bundfussr I feel like this is good to merge in - the step you add in the GHA makes sense and takes out a manual step. We can always revert if for some reason Remotes has to get back in.