-
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
Move split_upwards() to tskit? #27
Comments
It sounds like something that should be in tskit, I guess the only reason we put it here is so we wouldn't need to do so much testing and worrying about corner cases |
Should probably rename to split_pastwards or something also? |
I think it's going to be totally used by people - it's shown up in three or four different people's work independently. In testing, the thing to check is whether for each edge, the subtree below that edge doesn't change. |
Do we have a tskit ready implementation? |
Seems like a good idea to me. @jeromekelleher -- the closest we have is the numba version you wrote (using the tree position jitclass) Line 106 in 2777319
so this would need to be moved to C I suppose |
That would be a fair bit of work to port to C |
I can port it over, will be next month at the earliest though. We could put in a pure-python method if it seems convenient enough to have around in the meantime |
I'm in no hurry! Pure Python would be too slow to be useful. |
The existing numba version would not be considered for tskit because you aim for both C and Python API @jeromekelleher? |
Tskit is quite strict about adding dependencies (for various reasons) and we don't currently have a dependency on numba. In practise, numba is quite a tricky dependency, so we would need very good reason indeed to add it to tskit. |
Another issue is that the current numba implementation isn't faster than the python version. The code:
|
Hm, probably |
This is going to be significant work to add to tskit - I'd vote for focusing on other bigger impact stuff. |
I agree with Jerome. In small tree sequences for testing, python ver. is already pretty fast unless the population structure is complicated. For big sequences, we're not gonna use it anyway because of the memory demand. |
One possibility would be to write a short thing for the docs about the operation and give the python code there? |
We don't necessarily need
split_upwards()
anymore with the new matvec (tree-seq-based-GRM-times-a-vec) algorithm. However, it's good to have this functionality for testing etc.I am working with @jeromekelleher on adding edge effect, edge value, and node value functionality to
tstrait
(see tskit-dev/tstrait#155). As part of testing this work, I am finding it handy to have thesplit_upwards()
, which makes me wonder ifsplit_upwards()
should be intskit
(instead intslmm
).Thoughts?
The text was updated successfully, but these errors were encountered: