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
Use scikit-hep vector to as the backend for vector math in nanoevents #992
Comments
Please let me know if I can help with this, or if I can take up a few specific modules to refactor. I would be slow (not familiar with coffea's codebase as of now), but this could be a nice starting point for my fellowship project! |
@Saransh-cpp I already made a first try at backing nanoevents.methods.vector with scikit-hep vector over in #991. Have a look if you like, that probably gives you a good idea of where things line up or don't line up in terms of the interfaces. |
But if you want to pick up the work and discuss with us from there we're very happy to have you join in! |
Would definitely like to pick something up! Are there any coffea meetings that I can join? |
We could restart the coffea developers meetings, but since it's only one person I think a reasonable place to have a chat would be in the dask-awkward chats Fridays at 9am central time. @jpivarski would it be OK to use some time in that meeting for this discussion? |
Let's not take over the dask-awkward meeting for this, since it's not directly related to Dask. It might lead to Dask pretty quickly if the Vector behaviors don't work on Dask, although I actually don't expect that. (The Vector behaviors are written entirely in terms of ufuncs, which should be Dask-ready as a whole category.) So Saransh should join us there also (ask me on Slack if you need the Zoom link). We could use the Coffea Developers meeting place and time and only the few of us meet, depending on when that is. |
We haven't had that meeting for years at this point. I think a quick 1:1 will suffice then. |
We had discussed this migration quite some time ago, and we think it's the right way to go since nanoevents vector definitely influenced scikit-hep's vector.
We also need to understand how to properly deal with
nearest
andmetric_table
. It might just be better to promote those to free functions and then we can just have the higher level physics concept classes inherit directly from scikit-hep vector.In addition to the above which would be a rather breaking change, we'll have to be careful to plan out a few deprecation cycles so that users are caught unaware by small differences like
delta_phi
vs.deltaphi
and similar.The text was updated successfully, but these errors were encountered: