-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide more useful error message for UnitSpherical transformations without a common origin #4210
Comments
Thanks for the test run, @barentsen! The first one is definitely a bug - it never even occurred to me that lambda is a reserved word in this context, but it's obvious as soon as you said it! I'm thinking the best solution is to change it to And that's because yes, my understanding is that there is indeed a distinction - if you are using a geocentric ecliptic system, the traditional variables are apparently lambda/beta/delta, while for heliocentric (which by inference I decided also makes sense for barycentric), the l/b/r or d convention seems to be more standard. This is based on a pretty flimsy set of examples, though - a textbook that I promptly lost track of, and the wikipedia page on ecliptic coordinates. So if you or someone else that actually uses these systems knows better, it could certainly be changed! For the second item, though, I don't think that's a bug, but rather a feature. The reason why is that the >>> crd3d = SkyCoord(0*u.deg, 0*u.deg, distance=100*u.au)
>>> crd3d.heliocentrictrueecliptic
<SkyCoord (HeliocentricTrueEcliptic: equinox=J2000.000): (l, b, r) in (deg, deg, AU)
(359.9977336, -0.00012388, 100.0071365)>
>>> crd3d.barycentrictrueecliptic
<SkyCoord (BarycentricTrueEcliptic: equinox=J2000.000): (l, b, r) in (deg, deg, AU)
(359.99613188, -0.00000574, 100.0)> with the key difference being the presence of the You may have been fooled by the fact that |
Thanks for the detailed and enlightening explanation @eteq! I am going to try to read about this to get a better understanding, but all sounds reasonable at first read :-) Note that it would be nice to have the second item raise an exception that says something like: By the way, I was wondering if we could offer the user a clear default, i.e. |
#4211 should fix the lambda problem. As I said above if you have any reason to think the lamb/beta/delta scheme is not actually used I'm happy to hear it, as I've never actually used ecliptic coordinates myself for anything. But absent someone who can speak to the matter I'm sticking with wikipedia ;) But you do raise a very good point, @barentsen, that a more useful error message would make things a lot clearer. Perhaps We should consider #4211 as closing this, but you could create a separate issue to make error messages better when a frame that's UnitSpherical is transformed to something with a different origin? If you're feeling adventurous you could even try to implement it yourself (I'm happy to point you in the right direction if so). |
@eteq Could you point me in the right direction, in a few words, re. the improved error message? Happy to do things that allows you to work on other stuff :-) |
@barentsen - the basic idea is to try to surround the place that gives the The trick is where in the call stack - ideally this would be somewhere that makes it so that other frames (not just the ecliptic ones) also give the same message. Perhaps in the |
I'm re-assigning this to v1.2 and changed the name to reflect what it has now morphed into. |
GeocentricTrueEcliptic
and HeliocentricTrueEcliptic
It seems to have been solved in the meantime. The first example works on master and the message for
|
So, can we close this? |
Ideally we should wait for @barentsen to confirm that he's happy with the current status. |
I confirm that @barentsen is happy with the improved error message! |
#3749 recently added support for ecliptic coordinates (which makes me super happy, yay!! 👍 @eteq 👍)
I started playing with it and noted two glitches.
First, the
GeocentricTrueEcliptic
class has alambda
parameter, which causes trouble becauselambda
is a reserved word, e.g. resulting in a syntax error when trying to access the value:It looks like
lambda
will need to be renamed, but I can't offer a suggestion into what. I was already quite surprised thatBarycentricTrueEcliptic
usesl
whereasGeocentricTrueEcliptic
useslambda
, is that an accident or do both frames indeed use different language?Secondly, I ran into a
UnitConversionError
when accessingHelioCentricTrueEcliptic
.I verified that these issues affect both 3.4 and legacy Python.
The text was updated successfully, but these errors were encountered: