-
[x] I have checked that this issue has not already been reported.
-
[x] I have confirmed this bug exists on the latest version of pandas.
-
[x] (optional) I have confirmed this bug exists on the master branch of pandas.
Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.
Code Sample, a copy-pastable example
Index.union
treats nan
differently than MultiIndex.union
. Same goes for intersection.
idx1 = Index([1, np.nan])
idx2 = Index([1, np.nan, 3])
idx1.union(idx2)
idx1.intersection(idx2)
mi1 = MultiIndex.from_arrays([[1, np.nan]])
mi2 = MultiIndex.from_arrays([[1, np.nan, 3]])
mi1.union(mi2)
mi1.intersection(mi2)
Output:
Float64Index([1.0, 3.0, nan], dtype='float64')
Float64Index([1.0, nan], dtype='float64')
MultiIndex([(1.0,),
(nan,),
(nan,),
(3.0,)],
)
MultiIndex([(1.0,)],
)
Problem description
Inconsistent behavior is a problem. Additionally if both MultiIndexes are equal nan is only returned once. When not matching nan is the desired output, we have to adjust for theses cases before checking for equality.
Expected Output
I am not quite sure what to expect, but taking the current behavior of merges into account, I think it would be more reasonable to return
MultiIndex([(1.0,),
(nan,),
(3.0,)],
)
MultiIndex([(1.0,),
(nan,)],
)
for the MultiIndex operations. Thoughts @jbrockmendel ?
related to #38439
Output of pd.show_versions()
Comment From: jbrockmendel
agreed