Skip to content

BUG: Fix Categorical use_inf_as_na bug #33629

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.

Sign up for GitHub

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

Merged
merged 19 commits into from
Apr 27, 2020
Merged

BUG: Fix Categorical use_inf_as_na bug #33629

Show file tree
Hide file tree
Changes from 6 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
8985831
BUG: Fix use_inf_as_na bugs
dsaxton Apr 18, 2020
55ed2cf
Note
dsaxton Apr 18, 2020
9582927
Issue number
dsaxton Apr 18, 2020
365df7e
Oops
dsaxton Apr 18, 2020
1d05145
Different check
dsaxton Apr 19, 2020
a1b12ba
Merge remote-tracking branch 'upstream/master' into use-inf-as-na
dsaxton Apr 19, 2020
c7c03b8
Remove StringArray stuff
dsaxton Apr 19, 2020
dbf9830
Fix
dsaxton Apr 19, 2020
60c7625
Update
dsaxton Apr 20, 2020
6b413b4
Merge remote-tracking branch 'upstream/master' into use-inf-as-na
dsaxton Apr 20, 2020
ddff3d2
Use equality instead
dsaxton Apr 20, 2020
cbfdd6a
Delete _isna_ndarraylike_old
dsaxton Apr 21, 2020
81c310f
Merge remote-tracking branch 'upstream/master' into use-inf-as-na
dsaxton Apr 21, 2020
1838a33
Add some tests
dsaxton Apr 21, 2020
11d50a9
Fix test
dsaxton Apr 21, 2020
afa9448
Add docstring
dsaxton Apr 26, 2020
c7b65d5
Merge remote-tracking branch 'upstream/master' into use-inf-as-na
dsaxton Apr 26, 2020
a95f38c
Fix
dsaxton Apr 27, 2020
fe1648f
Nit
dsaxton Apr 27, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion doc/source/whatsnew/v1.1.0.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -445,6 +445,7 @@ Categorical
- :meth:`Categorical.fillna` now accepts :class:`Categorical` ``other`` argument (:issue:`32420`)
- Bug where :meth:`Categorical.replace` would replace with ``NaN`` whenever the new value and replacement value were equal (:issue:`33288`)
- Bug where an ordered :class:`Categorical` containing only ``NaN`` values would raise rather than returning ``NaN`` when taking the minimum or maximum (:issue:`33450`)
- Bug where :meth:`Series.isna` and :meth:`DataFrame.isna` would raise for categorical dtype when ``pandas.options.mode.use_inf_as_na`` was set to ``True`` (:issue:`33594`)

Datetimelike
^^^^^^^^^^^^
Expand Down Expand Up @@ -638,7 +639,7 @@ ExtensionArray
^^^^^^^^^^^^^^

- Fixed bug where :meth:`Serires.value_counts` would raise on empty input of ``Int64`` dtype (:issue:`33317`)
-
- Fixed bug where :meth:`StringArray.isna` would return ``False`` for NA values when ``pandas.options.mode.use_inf_as_na`` was set to ``True`` (:issue:`33594`)


Other
Expand Down
3 changes: 2 additions & 1 deletion pandas/_libs/missing.pyx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,7 @@ def isnaobj_old(arr: ndarray) -> ndarray:
- INF
- NEGINF
- NaT
- NA

Parameters
----------
Expand All @@ -160,7 +161,7 @@ def isnaobj_old(arr: ndarray) -> ndarray:
result = np.zeros(n, dtype=np.uint8)
for i in range(n):
val = arr[i]
result[i] = val is NaT or _check_none_nan_inf_neginf(val)
result[i] = checknull(val) or val == INF or val == NEGINF
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this related to the OP in #33594?. I think the NA checking for string dtype #33594 (comment) maybe should be a separate issue/PR. We may want to backport the fix relating to the change in return type of Categorical.ravel from numpy array to Categorical.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unrelated, I found this other bug while debugging the original issue and decided to fix it here. I'll go ahead and separate it out for easier bookkeeping.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to #33656

Copy link
Member Author

@dsaxton dsaxton Apr 19, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, they are kind of related in that a fix needs to be made to missing.py as well. I'll wait to see how that ends up here before making the associated change in the other PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one is a bug in _isna_ndarraylike_old and the other is a bug in isnaobj_old. They are related but I think should be treated indepedently.

for the NA issue (bug in isnaobj_old once bug in _isna_ndarraylike_old is fixed) we may want to add more tests for other extension arrays or add a test/parameterise an existing test in the base extension array tests.

return result.view(np.bool_)


Expand Down
6 changes: 5 additions & 1 deletion pandas/core/dtypes/missing.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -231,7 +231,11 @@ def _isna_ndarraylike(obj):


def _isna_ndarraylike_old(obj):
values = getattr(obj, "_values", obj)
if not isinstance(obj, np.ndarray):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the the same construct we use in isna_arraylike?

Copy link
Member Author

@dsaxton dsaxton Apr 19, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In _isna_arraylike it looks like we use getattr, but then check if we have an ExtensionArray and call the isna method if so

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree the code should use the same structure as _isna_ndarraylike, refactoring out the common code maybe advantageous to avoid divergence occurring again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you recommend using a similar pattern here? We can't rely on isna to catch infinity (it only works if you construct the array after setting the option):

[ins] In [1]: cat = pd.Categorical([1, 2, np.inf])

[ins] In [2]: pd.options.mode.use_inf_as_na = True

[ins] In [3]: cat.isna()
Out[3]: array([False, False, False])

[ins] In [4]: cat = pd.Categorical([1, 2, np.inf])

[ins] In [5]: cat.isna()
Out[5]: array([False, False,  True])

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so is there also a bug in Categorical.isna?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose you could call this behavior a bug, but I'm not sure if it's a problem with Categorical.isna (it's simply checking Categorical._codes, which makes total sense and shouldn't need to change in my opinion). IMHO the issue is more with trying to have the behavior of these constructors / methods respect hidden global variables instead of being well-defined in isolation (I could even see the merit of deprecating options like this rather than needing to patch every place where NA checking might happen)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to make this code substatially the same, difference only be the inf change.

values = obj.to_numpy()
else:
values = obj

dtype = values.dtype

if is_string_dtype(dtype):
Expand Down
26 changes: 25 additions & 1 deletion pandas/tests/arrays/categorical/test_missing.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,8 @@

from pandas.core.dtypes.dtypes import CategoricalDtype

from pandas import Categorical, Index, Series, isna
import pandas as pd
from pandas import Categorical, DataFrame, Index, Series, isna
import pandas._testing as tm


Expand Down Expand Up @@ -97,3 +98,26 @@ def test_fillna_array(self):
expected = Categorical(["A", "B", "C", "B", "A"], dtype=cat.dtype)
tm.assert_categorical_equal(result, expected)
assert isna(cat[-1]) # didnt modify original inplace

@pytest.mark.parametrize(
"values, expected",
[
([1, 2, 3], np.array([False, False, False])),
([1, 2, np.nan], np.array([False, False, True])),
([1, 2, np.inf], np.array([False, False, True])),
],
)
def test_use_inf_as_na(self, values, expected):
# https://github.com/pandas-dev/pandas/issues/33594
with pd.option_context("mode.use_inf_as_na", True):
cat = Categorical(values)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also test this with putting the Categorical creation outside of the option context?

Copy link
Member Author

@dsaxton dsaxton Apr 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out that actually fails interestingly enough: #33629 (comment) (if you set the option after constructing the object it loses its effect). What's even more strange is the value displays as NaN:

[ins] In [3]: arr = pd.Categorical([1, 2, np.inf])                                                                                                                                                           

[ins] In [4]: pd.options.mode.use_inf_as_na = True                                                                                                                                                           

[ins] In [5]: arr                                                                                                                                                                                            
Out[5]: 
[1.0, 2.0, NaN]
Categories (3, float64): [1.0, 2.0, NaN]

[ins] In [6]: arr.isna()                                                                                                                                                                                     
Out[6]: array([False, False, False])

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's even more strange is the value displays as NaN:

I think that is somewhat "expected", given the discussion above in #33629 (comment) (not that I like that behaviour though).

But regardless of how the categorical is created (with or without the option), I find it very strange that isna is then failing

Copy link
Member

@jorisvandenbossche jorisvandenbossche Apr 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, being a bit confused in the comment above :)
The Categorical.isna is failing, of course, since it just looks at -1 in the codes, and when inf is part of the categories, it is not -1 in the codes. Hence it is failing to detect it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaxton so could you additionally test it for pd.isna ? In constract to Categorical.isna(), pd.isna should work even if the Categorical is created before the context, I think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jorisvandenbossche Added some tests, let me know if this is roughly what you had in mind

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that looks good!

result = cat.isna()
tm.assert_numpy_array_equal(result, expected)

result = Series(cat).isna()
expected = Series(expected)
tm.assert_series_equal(result, expected)

result = DataFrame(cat).isna()
expected = DataFrame(expected)
tm.assert_frame_equal(result, expected)
22 changes: 22 additions & 0 deletions pandas/tests/arrays/string_/test_string.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -277,3 +277,25 @@ def test_value_counts_na():
result = arr.value_counts(dropna=True)
expected = pd.Series([2, 1], index=["a", "b"], dtype="Int64")
tm.assert_series_equal(result, expected)


@pytest.mark.parametrize(
"values, expected",
[
(pd.array(["a", "b", "c"]), np.array([False, False, False])),
(pd.array(["a", "b", None]), np.array([False, False, True])),
],
)
def test_use_na_as_inf(values, expected):
# https://github.com/pandas-dev/pandas/issues/33594
with pd.option_context("mode.use_inf_as_na", True):
result = values.isna()
tm.assert_numpy_array_equal(result, expected)

result = pd.Series(values).isna()
expected = pd.Series(expected)
tm.assert_series_equal(result, expected)

result = pd.DataFrame(values).isna()
expected = pd.DataFrame(expected)
tm.assert_frame_equal(result, expected)