[REVIEW] Support cupy array in quantile input

[galipremsagar]

Fixes: #8288 This PR fixes Series.quantile input q to support cupy array's.

[codecov]

Codecov Report

Merging #10429 (67c4418) into branch-22.04 (21ed251) will increase coverage by 0.18%.
The diff coverage is 100.00%.

❗ Current head 67c4418 differs from pull request most recent head 7b28368. Consider uploading reports for the commit 7b28368 to get more accurate results

@@               Coverage Diff                @@
##           branch-22.04   #10429      +/-   ##
================================================
+ Coverage         85.95%   86.14%   +0.18%     
================================================
  Files               139      139              
  Lines             22435    22435              
================================================
+ Hits              19285    19326      +41     
+ Misses             3150     3109      -41     

Impacted Files	Coverage Δ
python/cudf/cudf/core/column/column.py	89.27% <ø> (ø)
python/cudf/cudf/core/column/datetime.py	88.51% <100.00%> (-0.05%)	⬇️
python/cudf/cudf/core/column/numerical_base.py	98.88% <100.00%> (+1.06%)	⬆️
python/cudf/cudf/core/column/timedelta.py	90.45% <100.00%> (-0.05%)	⬇️
python/cudf/cudf/core/series.py	95.18% <100.00%> (+0.01%)	⬆️
python/cudf/cudf/core/column/string.py	88.91% <0.00%> (+0.12%)	⬆️
python/cudf/cudf/core/groupby/groupby.py	91.72% <0.00%> (+0.22%)	⬆️
python/cudf/cudf/core/tools/datetimes.py	84.49% <0.00%> (+0.30%)	⬆️
python/cudf/cudf/core/column/lists.py	90.69% <0.00%> (+0.46%)	⬆️
...thon/dask_cudf/dask_cudf/tests/test_distributed.py	86.79% <0.00%> (+67.92%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 40baeb4...7b28368. Read the comment docs.

[vyasr]

In addition to my one inline comment, I have one last question. Does it makes sense for the return_scalar logic to exist in the column layer at all, or would it be simpler to remove that parameter and always unpack the scalar in the Series method? In the interest of getting this merged for the release I'd be fine with postponing that change if you don't think it's quick to assess that now, but I think it's worth considering.

[vyasr]

Can this use _from_data?

[galipremsagar]

yeah updated to use _from_data

[galipremsagar]

In addition to my one inline comment, I have one last question. Does it makes sense for the return_scalar logic to exist in the column layer at all, or would it be simpler to remove that parameter and always unpack the scalar in the Series method? In the interest of getting this merged for the release I'd be fine with postponing that change if you don't think it's quick to assess that now, but I think it's worth considering.

I have given it a thought before but realized it'll end-up duplicating a lot of code for other methods like median which call in quantile, hence deferred to make those changes for now.

[vyasr]

In addition to my one inline comment, I have one last question. Does it makes sense for the return_scalar logic to exist in the column layer at all, or would it be simpler to remove that parameter and always unpack the scalar in the Series method? In the interest of getting this merged for the release I'd be fine with postponing that change if you don't think it's quick to assess that now, but I think it's worth considering.

I have given it a thought before but realized it'll end-up duplicating a lot of code for other methods like median which call in quantile, hence deferred to make those changes for now.

Yeah I noticed the same. Fine with me to defer, good to know you're already thinking about it 👍

[galipremsagar]

@gpucibot merge