-
Notifications
You must be signed in to change notification settings - Fork 4
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
Fix SF Quantities #370
Fix SF Quantities #370
Conversation
@gravesti - The "files changed" tab on GitHub here is miss-leading; as I've moved a chunk of code (without modification) between 2 functions the diff is just showing the difference between the code chunks immediately before the chunk I moved. I would potentially recommend viewing the complete file and not just the diff. |
Code Coverage Summary
Diff against main
Results for commit: 627b514 Minimum allowed coverage is ♻️ This comment has been updated with latest results |
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.
Looks good to me, @gowerc
just one bug I think
Updated to add the same test for the new claretBruno model which was merged in this morning |
Unit Tests Summary 1 files 154 suites 6m 44s ⏱️ Results for commit 627b514. ♻️ This comment has been updated with latest results. |
Unit Test Performance Difference
Additional test case details
Results for commit 8581191 ♻️ This comment has been updated with latest results. |
Closes #368
Ok so the actual bug fix was trivial was just a case of fixing a simple typo e.g.
gsf
->sf
. What was a bit more involved though was updating the unit tests to actually catch this error. It would have been easy to just compile all of the models but this would have added a ton of run time especially if we want to test each permutation of model / quantity generation.Instead I decided to abstract the code that generates the
StanModule
for the quantities into its own function so that we can just grab that object before its actually compiled. I then put together a mockJointModelSamples
object to which I then use to generate the correspondingStanModule
and then run the stan parser to make sure theres no obviously variable errors.I then added the unit test to our other longitudinal models to make sure no other bugs like this exist.
A bit of a red herring in these changes was that my original implementation tried to expand on the
write_stan()
function. I adapted the function to take a connection stream to which I was going to pipe the output to a variable. I abandoned this implementation for testing this PR but I thought having the function take a stream was a nice change so left it in as I had already written the code (hope thats ok).