-
Notifications
You must be signed in to change notification settings - Fork 912
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
Implement extract_datetime_component
in libcudf
/pylibcudf
#16776
Implement extract_datetime_component
in libcudf
/pylibcudf
#16776
Conversation
cpp/src/datetime/datetime_ops.cu
Outdated
{ | ||
CUDF_FUNC_RANGE(); | ||
switch (component) { | ||
case datetime_component::YEAR: return extract_year(column, mr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we plan to deprecate functions like extract_year
, we should reverse the call stack here.
This function should dispatch to return detail::apply_datetime_op<detail::extract_component_operator<...>, cudf::type_id::INT16>(column, stream, mr);
based on the enum, and we should make extract_year
call extract_datetime_component(column, datetime_component::YEAR, mr);
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made these changes with the latest commits - let me know if this is along the lines of what you meant.
from libcpp.memory cimport unique_ptr | ||
from pylibcudf.libcudf.column.column cimport column | ||
from pylibcudf.libcudf.column.column_view cimport column_view | ||
from pylibcudf.libcudf.scalar.scalar cimport scalar | ||
|
||
|
||
cdef extern from "cudf/datetime.hpp" namespace "cudf::datetime" nogil: | ||
cpdef enum class datetime_component(int32_t): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @bdice suggests, make the underlying type explicit in the C++ and then match it here.
pa.scalar(1694004645123456789, pa.timestamp("ns")), | ||
pa.scalar(1544024645123456789, pa.timestamp("ns")), | ||
pa.scalar(1682342345346235434, pa.timestamp("ns")), | ||
pa.scalar(1445624625623452452, pa.timestamp("ns")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we can't use conversion from datetime? It's also not obvious to me that these are the same timepoints as before.
Co-authored-by: Bradley Dice <[email protected]> Co-authored-by: Lawrence Mitchell <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do a little tidy-up in the implementation on the C++ side, I think.
I'm having a little trouble figuring out why this warning/error is being generated during the docs build:
Can anyone spot what I've got wrong? Maybe @bdice |
I'm not sure. Maybe try |
I built the docs locally and Edit: It should be in this part of the docs, but it isn't |
I noticed |
Co-authored-by: Matthew Murray <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving the python changes. This begs the question, why did cudf::extract_datetime_component
work, but not cudf::datetime::extract_datetime_component
? It looks like extract_datetime_component
is in the datetime namespace.
/merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few requests / questions.
@bdice any last thoughts here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My last round of comments was addressed -- approving.
Closes #16735