Open telegraphic opened 6 years ago
Thanks for finding these bugs.
Couldn't you use http://docs.astropy.org/en/stable/api/astropy.coordinates.Angle.html#astropy.coordinates.Angle.dms
Astropy does seem like a heavyweight solution for this. How/where do you need to interact with the angle value in the headers? E.g., are you setting them in a source block, loading them from a Sigproc read block, something else? I guess we need to decide on a standard representation of them in headers.
Yes, generally read from guppi raw files, which are often strings (unsure what the spec is, or if people actually follow it).
An yes, that code is particularly horrible (not written by me in my defense!), and came from a non-astropy-using codebase.
Astropy angles and units (http://docs.astropy.org/en/v0.2.1/units/index.html) are both pretty useful. I think we either use them extensively (instead of pint?), or not at all...
@telegraphic is this still a thing? It looks like the crash has been fixed but nothing was done about the angle representation.
The current sigproc reader block a) doesn't treat angles correctly, and b) will crash in most cases! My fix so far has been to use astropy, but that adds a dependency, so starting an issue to discuss merits.
Angles
The sigproc definition for angles is actually a float, HHMMSS.ss. For example, 17h45m00.12s needs to be written as a float 174500.12. This code is ugly but parses hms or dms:
Crash bug
The code fails on L204 and L291 as
axnames
is of type list, while the RHS a tuple.Easiest fix is: