-
Notifications
You must be signed in to change notification settings - Fork 932
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
Remove cudf.Scalar from shift/fillna #17922
Changes from all commits
388824f
2a677b3
79d066f
f3cccc8
85c6bff
9962d04
011c3c7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -24,7 +24,8 @@ | |
DecimalDtype, | ||
) | ||
from cudf.core.mixins import BinaryOperand | ||
from cudf.utils.dtypes import CUDF_STRING_DTYPE | ||
from cudf.core.scalar import pa_scalar_to_plc_scalar | ||
from cudf.utils.dtypes import CUDF_STRING_DTYPE, cudf_dtype_to_pa_type | ||
from cudf.utils.utils import pa_mask_buffer_to_mask | ||
|
||
if TYPE_CHECKING: | ||
|
@@ -165,16 +166,35 @@ def _binaryop(self, other: ColumnBinaryOperand, op: str): | |
|
||
return result | ||
|
||
def _scalar_to_plc_scalar(self, scalar: ScalarLike) -> plc.Scalar: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now that #17422 is merged I think we can stop special-casing this and see if anything breaks. WDYT? It does mean that decimal conversions in tests will fail if run with an older version of pyarrow, but I think that's an OK tradeoff. We might have to put some conditional xfails into our test suite for the "oldest" test runs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I opened #18035 to dedicate to avoid the decimal special casing. Can discuss on that PR, but IIUC, to avoid these conversion on the Python side, we would need pyarrow APIs introduced in pyarrow 19 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good call. Let's discuss there, I responded in #18035 (comment) |
||
"""Return a pylibcudf.Scalar that matches the type of self.dtype""" | ||
if not isinstance(scalar, pa.Scalar): | ||
# e.g casting int to decimal type isn't allow, but OK in the constructor? | ||
pa_scalar = pa.scalar( | ||
scalar, type=cudf_dtype_to_pa_type(self.dtype) | ||
) | ||
else: | ||
pa_scalar = scalar.cast(cudf_dtype_to_pa_type(self.dtype)) | ||
plc_scalar = pa_scalar_to_plc_scalar(pa_scalar) | ||
if isinstance(self.dtype, (Decimal32Dtype, Decimal64Dtype)): | ||
# pyarrow.Scalar only supports Decimal128 so conversion | ||
# from pyarrow would only return a pylibcudf.Scalar with Decimal128 | ||
col = ColumnBase.from_pylibcudf( | ||
plc.Column.from_scalar(plc_scalar, 1) | ||
).astype(self.dtype) | ||
return plc.copying.get_element(col.to_pylibcudf(mode="read"), 0) | ||
return plc_scalar | ||
|
||
def _validate_fillna_value( | ||
self, fill_value: ScalarLike | ColumnLike | ||
) -> cudf.Scalar | ColumnBase: | ||
) -> plc.Scalar | ColumnBase: | ||
"""Align fill_value for .fillna based on column type.""" | ||
if isinstance(fill_value, (int, Decimal)): | ||
return cudf.Scalar(fill_value, dtype=self.dtype) | ||
return super()._validate_fillna_value(fill_value) | ||
elif isinstance(fill_value, ColumnBase) and ( | ||
isinstance(self.dtype, DecimalDtype) or self.dtype.kind in "iu" | ||
): | ||
return fill_value.astype(self.dtype) | ||
return super()._validate_fillna_value(fill_value) | ||
raise TypeError( | ||
"Decimal columns only support using fillna with decimal and " | ||
"integer values" | ||
|
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.
This feels a bit odd as a class method. I feel like a free function that accepts a dtype would be more appropriate, then we could call that with
col.dtype
. Scoping-wise this doesn't feel like a Column method. Plus then it would directly mirrorpa_scalar_to_plc_scalar
.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.
I guess there is currently a small benefit because we can override this method for decimal columns to get the specialized behavior that we need, but I think that we don't need that any more (see my comment on that class).
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.
Now that I've closes #18035 as an attempt to avoid this decimal special casing, do you still feel strongly about having this as a free function? I chose a class method because, as you mentioned, I am able to customize this for decimal and it's a little more obvious when I could remove this in the future
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.
No, I think it's fine to leave it as is for now.