-
Notifications
You must be signed in to change notification settings - Fork 1
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
Pass frequencies (instead of probabilities) to objects #17
Comments
Partially realized (thanks Nico!), but still awaiting thorough testing and refinement. |
Let's generalize this issue to accommodate additional types of scenarios (beyond the primary case of test results in medical diagnostics): Defining a scenarioTo represent any m x n contingency table, a user could define
For instance, a possible x-dimension could be "treatment" (with levels "medication", "placebo") and a corresponding y-dimension could be "outcome" (with levels "cured", "not cured"). To initialize a scenario, a user would either have to provide a (vector or matrix) of all m x n frequencies, or a sufficient set of essential probabilities (and either provide or compute a suitable population size N). Perspectives on a scenarioDistinguish between 3 different perspectives (binary splits):
In the diagnostic case, these perspectives are mapped onto the semantics of
Contingency table as outputGiven this basic input structure for scenarios (of various types), we include printing a (minimal vs. full) contingency table as an output (e.g., a function Overall, these changes would merely affect some variable labels and the semantics (e.g., names and colors) of some frequencies and probabilities. While preserving everything implemented so far, the changes would allow for representing a much wider range of possible scenarios (including cases of evaluating treatments, prevention, and causality). |
Rethink & generalizeThe ideas mentioned in this issue are still good and valid, but should be generalized further: Essentially, we should implement the steps of the matrix lens model (i.e., filtering, framing, focusing, and presenting, see Neth et al., 2021, doi 10.3389/fpsyg.2020.567817), starting either (a) from raw data or (b) from a description (and corresponding simulation). |
(Reopened this issue, as it hasn't been resolved yet.) |
To define a riskyr object, we currently pass 3 essential probabilities (prev, sens, spec). However, we also have functions translating from probabilities into frequencies (and vice versa). Hence, why not allow passing any of these to define a riskyr object?
The text was updated successfully, but these errors were encountered: