API: make all comparisons with NaT false #7001

shoyer · 2016-01-13T04:45:49Z

Now, NaT compares like NaN:

NaT != NaT -> True
NaT == NaT (and all other comparisons) -> False

We discussed this on the mailing list back in October:
https://mail.scipy.org/pipermail/numpy-discussion/2015-October/073968.html

~~This PR still needs a release note and probably some clean up on the tests -- the style I used in test_datetime.py (adding assert_array_equiv) is a little unusual.~~

CC @PythonCHB @jreback @mwiebe

shoyer · 2016-01-13T06:14:27Z

There are a couple of tests in test_multiarray that are failing -- they need an update to use a routine like assert_array_equiv, too.

jreback · 2016-01-13T13:43:24Z

👍 lgtm

mwiebe · 2016-01-13T17:09:32Z

numpy/core/tests/test_datetime.py

+    assert_array_compare(lambda x, y: (x == y) | ((x != x) & (y != y)),
+                         x, y, err_msg=err_msg, verbose=verbose,
+                         header='Arrays are not equivalent')
+


It would probably be better not to introduce a new method like assert_array_equiv, and rather use the assert_array_equal that's already defined in numpy.testing?

numpy/numpy/testing/utils.py

Line 743 in 4c2b198

def assert_array_equal(x, y, err_msg='', verbose=True):

It probably needs to be updated to handle this NaT change.

I would agree, but assert_array_equal already defines the opposite for NaN. My guess is that changing assert_array_equal on NaN would break existing tests, but I also don't want to introduce a new inconsistency between NaN and NaT -- that's what I'm trying to fix here! This suggests that the safest path forward is to add a new testing function.

On Wed, Jan 13, 2016 at 9:09 AM, Mark Wiebe [email protected]
wrote:

@@ -20,6 +21,18 @@
_has_pytz = False

+def assert_array_equiv(x, y, err_msg='', verbose=True):

"""

Raises an AssertionError if two array_like objects are not equivalent.

Equivalent objects are either equal or each NaN/NaT in each position.

"""

assert_array_compare(lambda x, y: (x == y) | ((x != x) & (y != y)),

x, y, err_msg=err_msg, verbose=verbose,

header='Arrays are not equivalent')

It would probably be better not to introduce a new method like assert_array_equiv, and rather use the assert_array_equal that's already defined in numpy.testing?

numpy/numpy/testing/utils.py

Line 743 in 4c2b198

def assert_array_equal(x, y, err_msg='', verbose=True):

It probably needs to be updated to handle this NaT change.
Reply to this email directly or view it on GitHub:
https://github.com/numpy/numpy/pull/7001/files#r49618874

Can you show me what "the opposite for NaN" means? I thought it was the same behavior:

In [3]: import numpy as np In [4]: np.testing.assert_array_equal([np.nan], [np.nan]) In [5]: np.testing.assert_array_equal([np.nan], [3]) --------------------------------------------------------------------------- AssertionError Traceback (most recent call last)

I am mistaken!

I will certainly update assert_array_equal instead :)

shoyer · 2016-01-13T19:19:21Z

Per @mwiebe's advice, I fixed up assert_equal and assert_array_equal to handle NaTcomparisons properly instead of adding new testing API.

charris · 2016-01-13T19:45:57Z

Tests are failing. So, when you make the fixes might as well use the prefix TST, ENH:

shoyer · 2016-01-13T19:50:59Z

Oops, let's see how Travis likes this now...

I did not realize we used the TST prefix for test suite enhancements, but I suppose it makes sense -- I did adjust some tests here.

charris · 2016-01-13T20:03:15Z

numpy/testing/utils.py

@@ -343,16 +343,27 @@ def assert_equal(actual,desired,err_msg='',verbose=True):
        except AssertionError:
            raise AssertionError(msg)

+    def isnat(x):
+        return (hasattr(x, 'dtype')
+                and getattr(x.dtype, 'kind', None) in 'mM'


So all dtypes do not have a kind attribute? That's new to me, how does it happen?

Here's an example of a failing test:

====================================================================== ERROR: test_api.test_array_astype ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.4/site-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.4/site-packages/numpy/core/tests/test_api.py", line 234, in test_array_astype assert_equal(type(b), np.matrix) File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.4/site-packages/numpy/testing/utils.py", line 356, in assert_equal if isnat(desired) and isnat(actual): File "/home/travis/build/numpy/numpy/builds/venv/lib/python3.4/site-packages/numpy/testing/utils.py", line 347, in isnat return hasattr(x, 'dtype') and x.dtype.kind in 'mM' and x != x AttributeError: 'getset_descriptor' object has no attribute 'kind'

None is dangerous, it will raise an error with the string 'mM'. Using another string would work, say '_'.

charris · 2016-01-13T20:04:56Z

The prefixes are not always a good fit. The original use was for figuring out what to backport back when we were using svn.

shoyer · 2016-01-13T22:59:08Z

This is passing now.

Assuming we can get #6453 in for 1.11 as well, I'll a note about this change to the docs from that PR.

charris · 2016-01-13T23:57:03Z

numpy/testing/utils.py

    # Inf/nan/negative zero handling
    try:
        # isscalar test to check cases such as [np.nan] != np.nan
-        if isscalar(desired) != isscalar(actual):
+        if (isscalar(desired) != isscalar(actual)
+                and not (isinstance(desired, dtype)


Bit curious as to why dtype needs to be checked.

There are some masked array specific tests that use assert_equals to compare a dtype and the string version of a dtype (e.g., "float"). A string is a scalar, but a dtype is not.

On Wed, Jan 13, 2016 at 3:57 PM, Charles Harris [email protected]
wrote:

# Inf/nan/negative zero handling try: # isscalar test to check cases such as [np.nan] != np.nan

if isscalar(desired) != isscalar(actual):

if (isscalar(desired) != isscalar(actual)

and not (isinstance(desired, dtype)

Bit curious as to why dtype needs to be checked.
Reply to this email directly or view it on GitHub:
https://github.com/numpy/numpy/pull/7001/files#r49670305

added a comment

charris · 2016-01-13T23:59:58Z

Looking good. Could you add some tests in numpy/testing/tests/test_utils.py?

shoyer · 2016-01-14T18:29:51Z

Added tests to test_utils for the fixed testing routines

shoyer · 2016-01-14T19:24:12Z

Tests were failing due to my other recently merged datetime64 bug fix -- should be fixed now.

mhvk · 2016-01-14T19:29:24Z

numpy/ma/testutils.py

-            raise AssertionError(msg)
-        return
+        return utils.assert_equal(actual, desired)
+        # msg = build_err_msg([actual, desired], err_msg,)


Why leave the commented out code here?

good catch -- removed

charris · 2016-01-14T20:53:02Z

numpy/core/tests/test_datetime.py

+        td_other = np.timedelta64(1, 'h')
+        for op in [np.equal, np.less, np.less_equal,
+                   np.greater, np.greater_equal]:
+            assert not op(dt_nat, dt_nat)


Umm, use assert_ from numpy.testing. Plain old assert goes away when Python is run optimized.

Sorry I missed that earlier.

will do... I would be surprised if anyone is running our test suite with runtime optimized python though :)

Windows Python used to do so by default, I don't know if it still does.

Now, NaT compares like NaN: - NaT != NaT -> True - NaT == NaT (and all other comparisons) -> False We discussed this on the mailing list back in October: https://mail.scipy.org/pipermail/numpy-discussion/2015-October/073968.html

API: make all comparisons with NaT false

charris · 2016-01-14T23:33:06Z

Thanks Stephan.

This reverts commit 7141f40, reversing changes made to 8fa6e3b. The original broke some pandas tests. The current plan to get this in is * reversion * issue FutureWarning in 1.11 and 1.12 * make the change in 1.13.

Revert "Merge pull request #7001 from shoyer/NaT-comparison"

seberg · 2016-01-28T20:35:17Z

@shoyer, all. The current version has the problem of giving spurious FutureWarnings in the test suit/printing that were fixed here, but were removed agian during revert. I noticed when I tried to get my warning cleanup stuff further (with the idea of removing as many global warnings as possible).

It would be good to have an np.isnat function or include it into np.isnan, but IIRC there was a problem with that? One can fix these changes here also with view('i8') stuff.

Wanted to note this, we can maybe ignore the spurious warnings for 1.12?!

This reverts commit 7141f40, reversing changes made to 8fa6e3b. The original broke some pandas tests. The current plan to get this in is * reversion * issue FutureWarning in 1.11 and 1.12 * make the change in 1.13.

mwiebe reviewed Jan 13, 2016
View reviewed changes

shoyer force-pushed the NaT-comparison branch 2 times, most recently from 68aae57 to 6fcfb39 Compare January 13, 2016 19:14

charris added 05 - Testing component: numpy.testing 01 - Enhancement labels Jan 13, 2016

charris removed the 05 - Testing label Jan 13, 2016

shoyer force-pushed the NaT-comparison branch from 6fcfb39 to 81df65c Compare January 13, 2016 19:50

charris reviewed Jan 13, 2016
View reviewed changes

shoyer force-pushed the NaT-comparison branch 2 times, most recently from e06ca3a to 1d430c0 Compare January 13, 2016 21:45

charris reviewed Jan 13, 2016
View reviewed changes

shoyer force-pushed the NaT-comparison branch from 1d430c0 to c342256 Compare January 14, 2016 18:29

shoyer force-pushed the NaT-comparison branch from c342256 to 69460e3 Compare January 14, 2016 19:23

mhvk reviewed Jan 14, 2016
View reviewed changes

shoyer force-pushed the NaT-comparison branch from 69460e3 to a282e98 Compare January 14, 2016 19:30

charris reviewed Jan 14, 2016
View reviewed changes

TST, ENH: make all comparisons with NaT false

53ad26a

Now, NaT compares like NaN: - NaT != NaT -> True - NaT == NaT (and all other comparisons) -> False We discussed this on the mailing list back in October: https://mail.scipy.org/pipermail/numpy-discussion/2015-October/073968.html

shoyer force-pushed the NaT-comparison branch from a282e98 to 53ad26a Compare January 14, 2016 21:44

charris added a commit that referenced this pull request Jan 14, 2016

Merge pull request #7001 from shoyer/NaT-comparison

7141f40

API: make all comparisons with NaT false

charris merged commit 7141f40 into numpy:master Jan 14, 2016

shoyer deleted the NaT-comparison branch January 14, 2016 23:37

shoyer mentioned this pull request Jan 15, 2016

NaT comparison change breaks pandas test suite #7019

Closed

charris added a commit that referenced this pull request Jan 17, 2016

Merge pull request #7042 from charris/revert-7001

947b023

Revert "Merge pull request #7001 from shoyer/NaT-comparison"

Uh oh!

API: make all comparisons with NaT false #7001

API: make all comparisons with NaT false #7001

Uh oh!

Conversation

shoyer commented Jan 13, 2016

Uh oh!

shoyer commented Jan 13, 2016

Uh oh!

jreback commented Jan 13, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shoyer commented Jan 13, 2016

Uh oh!

charris commented Jan 13, 2016

Uh oh!

shoyer commented Jan 13, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

charris commented Jan 13, 2016

Uh oh!

shoyer commented Jan 13, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Bit curious as to why dtype needs to be checked.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

charris commented Jan 13, 2016

Uh oh!

shoyer commented Jan 14, 2016

Uh oh!

shoyer commented Jan 14, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

charris commented Jan 14, 2016

Uh oh!

seberg commented Jan 28, 2016

Uh oh!

Uh oh!

Bit curious as to why `dtype` needs to be checked.