issue_comments

OK, why don't we merge this, then I'll take a look at the remaining failing test? I think I can fix that by adjusting .travis.yml.

Okay - that worked. I think we're good with numpy 1.10 here. There is still one failing test related to pandas/numpy. This may be more of a travis thing.

ugh indeed. I'll figure out how to coerce the datetime64 object into something that works for now.

In any case, I was wrong about what had changed with NumPy 1.10. This appears to be inadvertent... (sigh).

Hmm. Something seem to have broken/changed with NumPy 1.10:

``` In [1]: import numpy as np

In [2]: np.datetime64('NaT') == np.datetime64('NaT') Out[2]: True

In [3]: np.datetime64('NaT') == np.datetime64('NaT', 'us') /Users/shoyer/miniconda/envs/tmp-np1.10/bin/ipython:1: DeprecationWarning: elementwise == comparison failed; this will raise an error in the future. #!/bin/bash /Users/shoyer/miniconda/envs/tmp-np1.10/bin/python.app Out[3]: False ```

I'm not quite sure what's going on there, so I'll file an issue in the NumPy repo.

In the meantime, we may want to update our test to coerce to datetime64[ns] first.

I'm actually going to paste the traceback from one of the test results (using py.test) to show how nonsensical this is:

``` =========================================================================================================== FAILURES ============================================================================================================ _____________ TestVariable.test_index_0d_not_a_time _____________

self = <xray.test.test_variable.TestVariable testMethod=test_index_0d_not_a_time>

def test_index_0d_not_a_time(self):
    d = np.datetime64('NaT')
    x = self.cls(['x'], [d])
    # Wasn't able to figure out why this was failing.
    # AssertionError: numpy.datetime64('NaT') != numpy.datetime64('NaT')

  self.assertIndexedLikeNDArray(x, d, None)

xray/test/test_variable.py:115:

xray/test/test_variable.py:61: in assertIndexedLikeNDArray self.assertEqual(variable.values[0], expected_value0)

self = <xray.test.test_variable.TestVariable testMethod=test_index_0d_not_a_time>, a1 = numpy.datetime64('NaT'), a2 = numpy.datetime64('NaT')

def assertEqual(self, a1, a2):

  assert a1 == a2 or (a1 != a1 and a2 != a2)

E AssertionError: assert (numpy.datetime64('NaT') == numpy.datetime64('NaT') or (numpy.datetime64('NaT') != numpy.datetime64('NaT')))

xray/test/init.py:154: AssertionError ```

I don't get how neither of these are true:

(numpy.datetime64('NaT') == numpy.datetime64('NaT') or\ (numpy.datetime64('NaT') != numpy.datetime64('NaT')))

Previously, NaT == NaT was true. Now it's false, like how NaN works.

@shoyer - I don't think this is true.

``` Python In [9]: import numpy as np

In [10]: t = np.datetime64('NaT')

In [11]: t == t Out[11]: True

In [12]: n = np.nan

In [13]: n == n Out[13]: False

In [14]: np.version Out[14]: '1.10.0' ```

I'll figure out something to do with the NaT comparison.

I think we're okay on Travis. We just have one failing test.

As for the verbosity of the numpy warnings. It is now just showing up in a lot more places (https://travis-ci.org/xray/xray/jobs/84683346#L665-L702). It seems like matplotlib and numpy itself haven't dealt with the warnings on their end yet.

The "numpy equal will not check object identity in the future" warning is really annoying. The problem is that we put NaN in object arrays to indicate missing values (like pandas). Equals on object arrays currently applies the elementwise check x is y or x == y, which of course is different from x == y for NaN.

Of course, we have our own check for NaN which means this warning isn't relevant for us. If the warnings have gotten more verbose, I'll take another look. If you're interested in trying out some fixes, this is where they originate from: https://github.com/xray/xray/blob/a2fa27004f6cac476a3dbec2fa0774716f05f198/xray/core/ops.py#L183

I'll futz with the Travis-CI settings and see if I can get it installing happily again.

NumPy fixed comparison operations with NaT in 1.10. Previously, NaT == NaT was true. Now it's false, like how NaN works.