-
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
Example #2: Group-dependent time-varying force of infection #41
base: main
Are you sure you want to change the base?
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.
I think the main thing to figure out is how this interacts with person properties if at all. The answer kind of depends on if you want similar interfaces for like mutation listeners/indexes and stuff, which you probably do.
I like the idea of internally enforcing the rules around one to one, one to many etc. depending on what relationship you define.
Might be worth providing some nice helper utilities for randomly assigning people into groups, but maybe that's overkill since it's not that hard
enum GroupTypes {Counties} | ||
|
||
#[derive(Debug, EnumIter)] | ||
enum Counties {A, B} |
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.
Instead of defining k
as a parameter, wouldn't it make more sense to have this derived from the total group types?
fn assign_and_plan_movement(context: &mut Context, | ||
person_creation_event: PersonCreationEvent) { | ||
// evenly distribute ppl among the counties | ||
let county_index = parameters.get_parameter(population_size) % parameters.get_parameter(k); |
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.
Is there a reason you want to do this differently from moving them (i.e. iterate through instead of randomly distributing them on the initial assignment?)
I would imagine this would end up as either an assign_random_group
function on PersonBuilder
(if this is how we end up interacting with person properties) or this is a assign_random_group
is a trait extension on context that takes a person id, and you set up the listener here.
// that gives that value of the CDF. | ||
// The math behind this is the same as drawing s ~ Exp(1), setting that equal to \int_0^t foi(u)du, | ||
// and solving for the time t at which the infection happens, which is fewer steps/easier. | ||
fn inverse_sampling_infection(context: &mut Context, person_id: PersonID) { |
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.
This is nice as a contrast to the other basic infection model. I wonder if this actually ends up being its own mini example?
README.md
specifying model andgroups.md
specifying my conception of theixa
groups
component for a food-borne illness that has a time-varying force of infection (i.e., seasonality) that varies by region/group. Rust pseudocode for the model. Any and all feedback appreciated -- the goal here is to not just think aboutixa
functionality but also howixa
structure can drive modularity -- and others are also welcome to review.