-
Notifications
You must be signed in to change notification settings - Fork 13
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
Improved treatment of doubling / halving time when growth rate estimate spans 0 #94
base: main
Are you sure you want to change the base?
Conversation
… of tests()) and regenerates reference files; passes all tests on second run of tests(); not committing new reference files
…_value() with update=FALSE; note that there is a bug in expect_equal_to_reference() such that update is reset from FALSE to TRUE (see testthat issue 683)
…s; need input from @thibautjombart on what expected behavior should be
…sired behaviour as a result of the change to doubling / halving interval CIs; committing new reference rds files
…it together; add test for this
…ups that have growth rates with different signs
…fits (see previous commit)
Note that I'm concerned that this PR and #90 both introduce new error messages that might break backward compatibility. |
Also, @thibautjombart: what do you think about squashing commits (eg the ones where I'm just adding spaces?) |
Can you explain what you mean by breaking backward compatibility? What breaks with #90 and this PR? I'm aware of the breaking change for character data and I might have a less break-y way of addressing that.
I don't know if there is a way to squash specific commits, either we take them all or squish them into one commit to rule them all. |
@jrcpulliam, Thank you for the contribution. Sorry it's taken me a bit to get to this. I have a couple of questions/comments on this:
|
For the growth rate, in this situation the CI is an exclusion interval:
So we may want to output something along the lines of I think part of the confusing stuff is we try to be clever in the output and report positive values as 'doubling times' and negative ones as 'halving times'. We could be more consistent and just report 'doubling/halving times', and explain that negative values are halving times? Re the error: I think it comes from the above, e.g. one group may have r>0 and therefore a 'doubling time', while another would have r<0 and halving times reported. |
I agree that the confusion is due to the way we handle the output. Currently, we try to detect whether r is negative or positive and then use that to determine if we want to use
This is in part because we based the conditional only on the first r value, which can be changed. The situation that would cause this condition is not that infeasible and we should be able to address it. All in all, I think that there is still room for us to give a sensible interpretation of the doubling/halving times. The way I see it, we calculate these values to make the lives of the users easier so that they have an easily interpret-able number they can report. We could do the following:
|
Yup yup yup. I agree with all the above! :) |
I'll have a go at this for the next next version of incidence. My priority right now is to get a working version on CRAN ASAP for #95 . |
expect_equal_to_reference()
that derives from a bug intestthat
Closes #28.