BUG: Frame attributes in sky coordinates do not obey Numpy broadcasting rules #8812
Description
Originally prompted by @mhvk in #8805 (comment).
The crux of the issue is this: this doesn't work:
from astropy import units as u
from astropy.coordinates import FK5
from astropy.time import Time
FK5(0*u.deg, 0*u.deg, equinox=time.Time(['J2000', 'J2001']))
whereas this does:
FK5([0]*2*u.deg, [0]*2*u.deg, equinox=Time(['J2000', 'J2001']))
The latter proves that there's nothing in the machinery to prevent this all working the way you'd want, but the fact that the former fails is a sign that the broadcasting is not working the way you'd expect - e.g. 1 + np.random.randn(2) works just fine so it seems like the former example here should.
I consider this a bug because it was always the intent for broadcasting to work naturally in places like this.
cc @adrn
Reacted by Stuart Mumford
Activity
Cadair commentedon Jun 11, 2019
👍 this could be super useful for a bunch of SunPy stuff.
mhvk commentedon Jun 12, 2019
@eteq - now that I look at your examples again, I vaguely recall that at the time we felt that attributes should not have a shape that includes dimensions that the coordinates do not have. Indeed, we specifically test that the attribute can be broadcast to the shape of the representation.
In principle, we can change this to a test that the attribute and the coordinates can be broadcast together - though for sure that means that we should then actually broadcast the coordinates (otherwise slicing will become strange), i.e., the output of your two examples should be identical (they both have shape
(2,). Is this what you envision?A question that arises is what to do with setting an attribute after the fact. It may not be crazy to insist that for that case the attribute must still be broadcastable to the instance's shape, so that we can guarantee that the instances shape does not change.
In fact, just doing it in the initializer might make things cleaner, as it may well be possible to avoid the specific logic for the case that a frame has no data
mhvk commentedon Oct 28, 2019
Doesn't seem like anybody is getting around to this, so removing milestone.
lpsinger commentedon Apr 15, 2021
I agree with that.
mhvk commentedon Apr 15, 2021
@lpsinger - as I wrote over in #11571, I think your example serves to make clear that really we need to fix this! It should not actually be all that hard....
[-]Make coordinates broadcast naturally across times[/-][+]BUG: Frame attributes in sky coordinates do not obey Numpy broadcasting rules[/+]Allow broadcasting of frame attributes
mhvk commentedon Jul 27, 2022
See also discussion following #13398 (comment), which showed that even the person who wrote the initial code continues to think that broadcasting works, when it at present does not.
EDIT: see in particular some failures described in #13398 (comment)
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes
Broadcast frames over both data and attributes (#15121)