-
Notifications
You must be signed in to change notification settings - Fork 87
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
Align selective sweeps API with DFEs #1082
Comments
Yeah, we definitely need a wrapper function for this to avoid confusion. It seems a bit awkward that the mutation type needs to have a dummy DFE, but if this simplifies the implementation then I guess it's a win. Perhaps the name of the function could be more explicit, e.g. |
I think having DFEs and intervals and mutation types is a lot, and kinda redundant, when we can do with just the first two. I'd really like to remove the I don't think it's too bad to have a 'dummy' DFE, actually, since that's a place that we can attach names and descriptions, which we can't do for a MutationType. I think we could get rid of |
so the next step after So perhaps we want a function like |
To summarize:
@andrewkern's proposal would get around this by (I think) adding a method that takes a contig and a bunch of other stuff and then both (a) sets up the mutation type/DFE in the contig and (b) sets up and returns the Events. But, this seems kinda hard, @andrewkern, since consider the example in the docs where there's several conditionings. To do as you propose, we'd have to have make up some way of passing this series of conditionings into the Here's another proposal: instead of
|
A string name for the mutation id is a great idea! We should probably transition to string names for the population id too. |
I think this is a case of "why not both?" i.e. i think we could provide convenience functions to the user to set up these commonly used models. for instance what if the code for sweeps were something like:
|
Closed by #1341 |
The API for incorporating selective sweeps works directly with mutation type IDs (i.e., they need to know what the SLiM ID of the mutation type will be once it is simulated). Here's the rewrite of that example using the
add_DFE
way of doing things from #1078:This works, but to make it easier, I propose making a new
Contig
method that does the (a) make a mutation type (b) make a DFE with that mutation type (c) add it with no intervals to the Contig steps, and (d) return the mutation type ID. (i.e., everything in the###
above) We could call thisContig.add_single_mutation_type
? Or, something more evocative? What do you think, @grahamgower?The text was updated successfully, but these errors were encountered: