[
https://issues.apache.org/jira/browse/ARROW-13364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382510#comment-17382510
]
Joris Van den Bossche commented on ARROW-13364:
-----------------------------------------------
bq. EqualOptions has a nans_equal member to control the behavior of comparisons
between NaNs. I assume this was included to satisfy the behavior of different
tools.
Note this is for a different operation: for a "full array, data-structure
equality" ({{arr1.equals(arr2) = True or False}}), and the option is added here
mainly for convenience (as often you want to regard NaNs in the same location
as equal when it comes to full array equality, and writing this out manually is
rather verbose, i.e. something like {{((a == b) | (a.isnan() &
b.isnan()).all()}}).
We don't have such an option for _element-wise_ comparisons (which is the type
of equality/comparison that is discussed in this issue)
> [C++] Should NaN comparison return false or NaN/NA?
> ---------------------------------------------------
>
> Key: ARROW-13364
> URL: https://issues.apache.org/jira/browse/ARROW-13364
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Jonathan Keane
> Priority: Major
>
> In working on ARROW-12964 we ran into some corner behaviors with {{NaN}} that
> don't match our (and R's) expectations. It appears that (any?) comparison
> with `NaN` results in false:
> {code:r}
> > Scalar$create(NaN) > 5
> Scalar
> false
> {code}
> though at least in R this would result in an NA value:
> {code:r}
> > NaN > 5
> [1] NA
> {code}
> The current behavior _does_ match numpy's behavior:
> {code:python}
> >>> np.nan > 5
> False
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
