-
Notifications
You must be signed in to change notification settings - Fork 3
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
Improves distribution of dummy data #2326
base: main
Are you sure you want to change the base?
Conversation
Deploying databuilder-docs with Cloudflare Pages
|
Dummy data generation will generate a larger population and then sample from it | ||
to improve the distribution of patients. This parameter controls how much larger. | ||
Lower values will be faster to generate, while larger values will get closer to | ||
the target distribution. |
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 it'd be helpful to users to give the default and an idea of what a small/large value is. i.e. 1 means no oversampling, 2 means oversampling by up to 2x the specified population size
Defines a "weight" expression that lets you control the distribution of patients. | ||
Ideally a patient row will be generated with probability proportionate to its weight, | ||
although this ideal will be imperfectly realised in practice. The higher the value of | ||
``oversample`` the closer this ideal will to being realised. |
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.
An example as we have for additional_population_constraints would be helpful. Will this always be a case()
?
This improves the distribution of dummy data through the strategy of oversampling: We produce a larger population of patients than requested, and then sample down to a subset of it according to some weighted distribution of values.
This weighting scheme is calculated in two ways:
It's also a good place to insert heuristics we might want to add (e.g. we could add default age and sex distributions, we could choose what proportion of nullable columns should be null, etc). This doesn't do any of that.
It does come with the cost of making dummy data slower. I think this is an OK tradeoff, and will be improved by anything that improves dummy data generation (in particular future work on making constraints satisfied more often)