You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several places throughout the package where using units would be extremely helpful to both the user and in reducing the number of validation checks needed, e.g. ccd_offset, rot_xy. I think it would be a good idea to impose astropy units wherever possible. This would also help to increase interoperability with sunpy and the sunpy affiliated package ecosystem.
For a formal description of what this looks like in sunpy, see SEP-0003
The text was updated successfully, but these errors were encountered:
Thanks for the reminder! Implementing units for these functions is on our todo list, but it is fairly low-priority since these functions are used internally and should rarely, if ever, be called by users directly (additionally, ccd_offset is one of the only bits of code we ported directly over from IDL, so we want to make sure to maintain consistency if possible).
Fair point about the internal use of those functions. I think I had just listed those as examples. Are there other user-facing functions that would benefit from taking units as inputs and giving units as outputs?
One place where this is already done is the EISMap class properties, e.g. the wavelength property.
There are several places throughout the package where using units would be extremely helpful to both the user and in reducing the number of validation checks needed, e.g.
ccd_offset
,rot_xy
. I think it would be a good idea to impose astropy units wherever possible. This would also help to increase interoperability with sunpy and the sunpy affiliated package ecosystem.For a formal description of what this looks like in sunpy, see SEP-0003
The text was updated successfully, but these errors were encountered: