-
Notifications
You must be signed in to change notification settings - Fork 0
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
Minimal counterfactualism #19
Conversation
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.
After working in #19, I was thinking to go even one step further, which is:
- When creating a new person, draw their disease history (timing of biological latent & infectious period)
- Immediately check for passive or active detection. Figure out the detection time, if any
- Create an "effective"(?) infectious period, and draw infection times from that
In other words, why not just scrap counterfactualism 100%?
Somehow this seems like fewer changes than #16. Did I overengineer something?
@@ -12,7 +13,6 @@ def __init__(self, params: dict[str, Any], seed: Optional[int] = None): | |||
|
|||
def run(self): |
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.
We should probably now just rename run_infections
-> run
This just removes the counterfactual. That looks like it shuffles code around, adds maximum outbreak sizes, restructures the simulation loop, and alters the widget. It also helps that I didn't think to actually re-do any of the tests, so this is at least one modified file short of being usable. (I will say I don't like the time truncation in #16. If you want to simulate until a maximum number of infections you need to truncate by time, not by person. If I'm 3 infections short of the maximum, the next three infections could come from anyone in this generation, I shouldn't just let the first person infect three more and stop.) |
I thought about doing something more like that. At the time I decided
That being said, I'm not against redoing it that way as long as you're not worried about the modularity bit. |
Got it, yes, #16 was more of an overhaul
Fair, we shouldn't be processing infections in a queue, but rather dealing with them in the order in which they happened. I fixed that. |
Have another look at #16, which is in a (I think) stable but not pretty state The nice thing in that approach is that we visit each infection only once |
Recommend closing in favor of #16 |
This PR takes #16 to the extreme and adds in some speed findings from #13.
Compared to main as of 3ba4e72, it appears to allow many more simulations per second (NB: simulations run for 3 generations)