Closed joshwlambert closed 4 months ago
@avallecam thanks for raising this. I've fixed the problem that meant you were unable to subset by both the author and the subset
option (in this case the sample_size
). Your original code should now work as expected once #226 is merged.
To answer your other question:
Is there a way to see what variables are available for a multi_epidist object?
There is not a standard method to see which variables can be used to subset. We provide the most common subsetting types are arguments to epidist_db()
and the subset
argument can be used for more unusual subsetting. The <epidist>
structure is consistent so the best way to see which variables are there to be subset by is to use the $
to look into an <epidist>
object.
If you think of a better way to inform users on subsetting options please let me know and I'll happily implement it into the package.
If you think of a better way to inform users on subsetting options please let me know and I'll happily implement it into the package.
I would not say that this is a better way, but flexible. As a user, I liked the possibility of using epiparam()
+ dplyr::filter()
as a combo to explore the whole database before using epidist_db()
or at list inherit the class until broken intentionally by the user.
I raised #224 and #225 mostly because epiparam()
was no longer exported to the namespace. If you can point me to the key discussions that led to this decision in #197 will be highly informative to me. Because, I still think that keeping it would keep the previous flexibility.
This was previously used in:
@avallecam I cannot remember whether there was any recorded discussion before the changes to remove <epiparam>
from {epiparameter}. I will search and if I find any I will link to it in this issue. Some initial comments about package complexity were raised in #151, and these led to the major refactor in #197. There were certain limitations with storing the data in a tabular form, both when saved as a csv or read into R as a <data.frame>
.
However, it seems clear that the need/benefit of having and easily accessible tabular form to the epidemiological parameter library is there so I propose adding an as.data.frame()
method for <multi_epidist>
to easily enable this transformation.
However, it seems clear that the need/benefit of having and easily accessible tabular form to the epidemiological parameter library is there so I propose adding an
as.data.frame()
method for<multi_epidist>
to easily enable this transformation.
Thank you for sharing the context of the limitations that guided that removal. I think you did get a sense of my main intention from #225 and this issue. If {epiparameter} can list me literature-reviewed distributions, I would also want to access any of them apart from the easiness (of following the selection criteria) that single_epidist
provides. Different users may prefer to use different ways to access them, so keeping that gate open may be a sensible decision.
For future plans, if {epiparameter} ends up being an API from a database server online, then {epiparameter} may be flexible enough to apply SQL commands before importing the data to an R session (like backends I read listed in {dbplyr}).
Discussed in https://github.com/epiverse-trace/epiparameter/discussions/217