Description
In #11757 (comment) (copied below), I noted that there were a few inconsistencies on how Longitude and Latitude are allowed to interact. Am not sure it is worth fixing, but leaving it here in case since the actual issue #11757 was about is fixed).
"""
Thanks for reporting! Looking in some detail, this is actually somewhat tricky, as in much of Quantity it is built in that quantity subclasses are compatible with each other as long as the units are equivalent. E.g., the following are arguably similar bugs:
Longitude('10d') + Latitude('20d')
# <Angle 30. deg>
np.stack([Longitude('10d'), Latitude('20d')])
# <Longitude [10., 20.] deg>
A possible way to solve this is:
- Replace the iteration over a list with
np.stack in
|
elif (isiterable(value) and len(value) > 0 and |
|
all(isinstance(v, Quantity) for v in value)): |
|
# Convert all quantities to the same unit. |
|
if unit is None: |
|
unit = value[0].unit |
|
value = [q.to_value(unit) for q in value] |
|
value_unit = unit # signal below that conversion has been done |
- In
Longitude and Latitude override __array_ufunc__ and __array_function__ and for all the likes of np.add and np.stack, etc., check that the types does not include Latitude and Longitude, respectively. (Or perhaps adjust Quantity.__array_ufunc__ and __array_function__ to allow such checks, though it would be bad to make everything slower just for this...).
The above is do-able but somewhat non-trivial, since one has to check carefully that one is not disallowing operations that might make sense.
"""
Expected behavior
Generally, an exception should be raised if one tries to let Longitude and Latitude interact -- though one should be careful not to break cases used in the wild where it is fairly obvious what the behaviour should be.
Note: A "won't fix" may be the correct solution!
How to Reproduce
- Get package from '...'
- Then run '...'
- An error occurs.
# Put your Python code snippet here.
Versions
import astropy
astropy.system_info()
Description
In #11757 (comment) (copied below), I noted that there were a few inconsistencies on how
LongitudeandLatitudeare allowed to interact. Am not sure it is worth fixing, but leaving it here in case since the actual issue #11757 was about is fixed)."""
Thanks for reporting! Looking in some detail, this is actually somewhat tricky, as in much of
Quantityit is built in that quantity subclasses are compatible with each other as long as the units are equivalent. E.g., the following are arguably similar bugs:A possible way to solve this is:
np.stackinastropy/astropy/units/quantity.py
Lines 346 to 352 in 94bea30
LongitudeandLatitudeoverride__array_ufunc__and__array_function__and for all the likes ofnp.addandnp.stack, etc., check that thetypesdoes not includeLatitudeandLongitude, respectively. (Or perhaps adjustQuantity.__array_ufunc__and__array_function__to allow such checks, though it would be bad to make everything slower just for this...).The above is do-able but somewhat non-trivial, since one has to check carefully that one is not disallowing operations that might make sense.
"""
Expected behavior
Generally, an exception should be raised if one tries to let
LongitudeandLatitudeinteract -- though one should be careful not to break cases used in the wild where it is fairly obvious what the behaviour should be.Note: A "won't fix" may be the correct solution!
How to Reproduce
# Put your Python code snippet here.Versions