test failures with numpy-dev: elementwise comparison failed

I'm seeing the following failure in astropy.coordinates with numpy-dev:

def test_frame_init():
        """
        Different ways of providing the frame.
        """
        sc = SkyCoord(RA, DEC, frame='icrs')
        assert sc.frame_name == 'icrs'

        sc = SkyCoord(RA, DEC, frame=ICRS)
        assert sc.frame_name == 'icrs'

        sc = SkyCoord(RA, DEC, 'icrs')
        assert sc.frame_name == 'icrs'

>       sc = SkyCoord(RA, DEC, ICRS)

astropy/coordinates/tests/test_sky_coord.py:192: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <[RuntimeError("maximum recursion depth exceeded") raised in repr()] SafeRepr object at 0x106f706c8>
args = [<Quantity 1.0 deg>, <Quantity 2.0 deg>, <class 'astropy.coordinates.builtin_frames.ICRS'>]
kwargs = {}

    def __init__(self, *args, **kwargs):

        # Parse the args and kwargs to assemble a sanitized and validated
        # kwargs dict for initializing attributes for this object and for
        # creating the internal self._sky_coord_frame object
        args = list(args)  # Make it mutable
>       kwargs = self._parse_inputs(args, kwargs)

astropy/coordinates/sky_coordinate.py:79: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <[RuntimeError("maximum recursion depth exceeded") raised in repr()] SafeRepr object at 0x106e6eea8>
args = [<Quantity 1.0 deg>, <Quantity 2.0 deg>, <class 'astropy.coordinates.builtin_frames.ICRS'>]
kwargs = {}

    def _parse_inputs(self, args, kwargs):
        """
            Assemble a validated and sanitized keyword args dict for instantiating a
            SkyCoord and coordinate object from the provided `args`, and `kwargs`.
            """
        valid_kwargs = {}

        # Put the SkyCoord attributes like frame, equinox, obstime, location
        # into valid_kwargs dict.  `Frame` could come from args or kwargs, so
        # set valid_kwargs['frame'] accordingly.  The others must be specified
        # by keyword args or else get a None default.  Pop them off of kwargs
        # in the process.
>       frame = valid_kwargs['frame'] = _get_frame_name(args, kwargs)

astropy/coordinates/sky_coordinate.py:140: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

args = [<Quantity 1.0 deg>, <Quantity 2.0 deg>, <class 'astropy.coordinates.builtin_frames.ICRS'>]
kwargs = {}

    def _get_frame_name(args, kwargs):
        """
        Determine the coordinate frame from input SkyCoord args and kwargs.  This
        modifies args and/or kwargs in-place to remove the item that provided
        `frame`.  It also infers the frame if an input coordinate was provided and
        checks for conflicts.

        This allows for frame to be specified as a string like 'icrs' or a frame
        class like ICRS, but not an instance ICRS() since the latter could have
        non-default preferred attributes which would require a three-way merge.
        """
        frame = kwargs.pop('frame', None)

        if frame is not None:
            # Frame was provided as kwarg so validate and coerce into corresponding frame.
            frame_cls = _get_frame_class(frame)
            frame_name = frame_cls.name
        else:
            # Look for the frame in args
            for arg in args:
                try:
                    frame_cls = _get_frame_class(arg)
                except ValueError:
                    pass
                else:
                    frame_name = frame_cls.name
>                   args.remove(arg)
E                   DeprecationWarning: elementwise comparison failed; this will raise the error in the future.

@eteq

Actually I'm also seeing this in astropy.units:

    def test_comparison(self):
        # equality/ non-equality is straightforward for quantity objects
        assert (1 / (u.cm * u.cm)) == 1 * u.cm ** -2
        assert 1 * u.m == 100 * u.cm
        assert 1 * u.m != 1 * u.cm

        # when one is a unit, Quantity does not know what to do,
        # but unit is fine with it, so it still works
        unit = u.cm**3
        q = 1. * unit
>       assert q.__eq__(unit) is NotImplemented
E       DeprecationWarning: elementwise comparison failed; this will raise the error in the future.

I think the astropy.units error is the real one, whereas the coordinates one is a byproduct

cc @eteq @mdboom @mhvk

I've tried a bunch of different things, but ultimately it may be a Numpy bug (or at least a failure to address the case where __array_prepare__ throws an exception and that should be treated as unequal, not an exception. I've filed an issue here: numpy/numpy#4709.

@mdboom

@mdboom - thanks for looking into it! It looks like numpy/numpy#4709 was closed by a patch that was meant to fix it, but I'm still seeing the issue in Astropy.

@astrofrog

@astrofrog: the applied patch does not directly restore the previous behavior, but should allow you to reproduce the desired behavior by overriding __eq__ et al.

EDIT: except that this doesn't work for comparisons with masked arrays or matrices etc. -- back to the drawing board

The problem with dealing with this in __array_prepare__ is that it is in the wrong layer --- it's a part of the ufunc mechanism, and the ufunc mechanism should ideally never return NotImplemented which is a special value that should only be used in the Python binops...

@astrofrog

Do we consider this a must-fix for 0.4? If so, what's the status, @astrofrog @mdboom ?

@eteq

@eteq - I don't think this is something that needs to hold up 0.4, as what is the "best" return value is unclear (and, really, we are just passing on a numpy message). I think for 0.4 it is fine to xfail the tests, and then keep the issue.

Ok, but we definitely do need to add conditional xfails so as not to have our test suite fail when the next numpy comes out, right?

@astrofrog

@astrofrog - that seems fine to me, unless a new numpy release is imminent. Do we have any idea what the timescale is?

Hmm, looks like 1.9 may be in the works... See here:

http://mail.scipy.org/pipermail/numpy-discussion/2014-May/070118.html

This was a month ago, and they are probably delayed, but it sounds like it's close. Maybe we should review #2583 now and consider it for 0.4.

Numpy 1.9.0b1 is already out (last week), so 1-3 weeks from now 1.9.0 will be out (see astropy/ccdproc#74 (comment))

@astrofrog

Looking over 0.4 milestone issues, this is one of the trickier ones. Since official numpy is still at 1.8, I'll go ahead and follow @astrofrog's suggestion to relabel this for 0.4.1. think it is fine to be considered a bug fix, and we do have #2583 to resolve it, but that still needs a bit of time and should not hold up the release (it could obviously also be labeled 0.4.1 if needed).

Add __numpy_ufunc__, adjust tests, remove numpy-dev bugs (closes astr…

@mhvk

I agree with @mhvk that this shouldn't hold up 0.4, but if #2583 is ready in time for whenever everything else is ready, we should try to squeak it in. Otherwise, we can do 0.4.1 whenever it's ready (so far, x.y.1 releases have occurred pretty soon after the x.y release for us...)

Add __numpy_ufunc__, adjust tests, remove numpy-dev bugs (closes astr…

This issue has been solved by #2927 (I checked against the current numpy master as well, where the only error I see is unrelated -- see #2937), so I am closing it. Of course, feel free to reopen if I'm wrong...

Navigation Menu

Repository navigation

test failures with numpy-dev: elementwise comparison failed #2483

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

test failures with numpy-dev: elementwise comparison failed #2483

Description

Activity

astrofrog commented on May 14, 2014

mdboom commented on May 14, 2014

astrofrog commented on May 14, 2014

pv commented on May 14, 2014

eteq commented on May 26, 2014

mhvk commented on May 27, 2014

eteq commented on May 27, 2014

5 remaining items

eteq commented on Jun 12, 2014

astrofrog commented on Jun 13, 2014

mwcraig commented on Jun 13, 2014

mhvk commented on Jun 17, 2014

eteq commented on Jun 18, 2014

mhvk commented on Sep 13, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions