Fix NaN handling in drop_list_duplicates - #7662
Conversation
…ng point numbers with NaN
Codecov Report
@@ Coverage Diff @@
## branch-0.19 #7662 +/- ##
===============================================
+ Coverage 81.86% 82.28% +0.42%
===============================================
Files 101 101
Lines 16884 17066 +182
===============================================
+ Hits 13822 14043 +221
+ Misses 3062 3023 -39
Continue to review full report at Codecov.
|
|
Rerun tests. |
|
Rerun tests. |
…ist_duplicates # Conflicts: # cpp/src/lists/drop_list_duplicates.cu
|
I'm just thinking of another solution: re-implement Note that we still have to call |
That's a good point. I forgot CUB's radix sort doesn't take iterators. I think your current implementation is the best we can do for now. |
jrhemstad
left a comment
There was a problem hiding this comment.
On second pass, another thought occurred to me. Instead of having to materialize the replaced NaN column, couldn't the equality comparator just be parameterized on nan_equality to determine whether -NaN and NaN are equal?
I thought about that, but couldn't apply it. Here is the reason: After sorting, |
Oh, interesting. That must be an implementation detail of the CUB segmented radix sort. Well, in that case, what you've done seems like the best we can do. |
…AL before calling to `has_negative_nans`
|
@gpucibot merge |
|
Rerun tests. |
|
Rerun tests. |
|
Rerun tests. |
|
rerun tests |
|
Rerun tests. |
This PR modifies the behavior of
drop_list_duplicatesto satisfy both Apache Spark and Pandas behavior when dealing withNaNvalue in floating-point columns data:NaNsare treated as different values, thus noNaNentry should be removed after callingdrop_list_duplicates.NaNsare considered as the same value, and even-NaNis considered as the same asNaN. Thus, only oneNaNentry per list will be kept.New tests have also been added to verify such desired behavior.