Repository navigation
Give option for coordinate preferred units #6184
Description
Currently, coordinate.ra auto-converts to deg -- it should be possible to have the units remain those input by the user -- see #4903 -- the conclusion after discussion was that this will have to be an option, so that we do not break back-compatibility.
My current thought:
-
SkyCoordgains a formatter, with a format defined via strings, similar toTime(and possibly with similar format classes that do the parsing of the coordinates).repruses this formatter. - The default format remains
deg,deg(or whatever would indicate that), but this would be inferred from a configuration item, which could also be something to indicate "infer from input" (again, a bit likeTime)
Activity
taldcroft commentedon Jun 12, 2017
One minor problem with this is that the input for SkyCoord is so flexible and so actually retaining the units and format of the original data is not practical:
One could stipulate that it will use the unit of the first element for the rest.
But in general adding a keyword to disable using preferred units would be fine.
mhvk commentedon Jun 12, 2017
@taldcroft - my preference would be to go towards a model like
Time, perhaps even including format classes (though we wouldn't necessarily want to store data on those); I edited my top comment to reflect that.eteq commentedon Jun 16, 2017
I'm receptive to the idea of something like format classes - that would probably be a fairly minor perturbation on the "recommended units" machinery that already exists (and hopefully even make that easier to understand). To maintain backwards compatibility I think we have to stick with the default being what we've done thus far... But give users the power to override them.
An important high-level question, though, is where these formatters would live. The recommended units currently live in the representations... and that's probably where the machinery should be for something more flexible. But the user-level selection (and state of which frame is the right one) should be at a higher level. I think probably the frame level is best because that's already where the choice of representation class is set statefully?
eteq commentedon Jun 16, 2017
(Also, I tentatively milestoned this for 3.0, meaning either actually doing it, or agreeing not to do it)
mhvk commentedon Jun 16, 2017
OK, sounds good. Note that I'd like to remove
recommended_unitfrom representations, since I think their functionality does not need (nor use) it at all -- your suggestion of having it on the frame seems the right one.Anyway, (well) after 2.0...
mhvk commentedon Jan 23, 2018
Just as an update on the above:
recommended_unithas been removed from the representations (#6858); that now all lives on the frames. Arguably, frames are the right place for any changes, as that is also where the current copying of data for representation in degrees gets done.maxnoe commentedon May 12, 2021
@mhvk wouldn't it also help performance if the default transformation was to rad? I imagine this would make many transformations later for trigonometric functions unnecessary.
mhvk commentedon May 12, 2021
@maxnoe - the issue is specifically about how
sc.raandsc.declook, which are currently calculated from the representation. Nevertheless, you are right that if the representation itself was inradian, things would be a bit faster. In principle, even now you can do that by ensuring your inputs are in radian already. I'd guess, though, that the speed is likely limited by conversion toCartesian, etc. (so, perhaps one should input cartesian representations for maximum speed?!).