Skip to content

transform_to(AltAz) de-scalarizes if input has a distance #3920

Closed

Description

@eteq

Surprising behavior noted (indirectly) by @bmorris3 :

>>> aa = AltAz(location=EarthLocation.from_geodetic(0*u.deg, 0*u.deg, 0),obstime=Time('2015-1-1'))
>>> m=SkyCoord(10*u.deg,3*u.deg)
>>> m.transform_to(aa).shape
()

That part makes sense: the input is a scalar so the output is too

>>> aa = AltAz(location=EarthLocation.from_geodetic(0*u.deg, 0*u.deg, 0),obstime=Time('2015-1-1'))
>>> m=SkyCoord(10*u.deg,3*u.deg, 1*u.AU)
>>> m.transform_to(aa).shape
(1,)

oops! For some reason it decided to switch to a length-1 array coordinate. Definitely should still be a scalar.

This is definitely a bug and not at all intended, but changing it is breaking backwards-compatibility. How do we want to address this? Deprecation? Or leave it in for 1.0.x but change it for 1.1.x?

I'm not sure how used this functionality is right now, so it may not be an issue to slip in the change...

cc @adrn @astrofrog

Activity

  1. self-assigned this
    on Jul 7, 2015
  2. added this to the v1.1.0 milestone on Jul 7, 2015
  3. astrofrog commented on Jul 7, 2015

    @astrofrog
    Member

    I don't think we really need to preserve backward compatibility for buggy behavior like this. But can you give an example of realistic code that would break because of this assumption to see what we can do?

  4. modified the milestones: v1.0.4, v1.1.0 on Aug 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions