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
I'm curious of the thoughts of creating a type along the lines of CartCoords, UnitCoords, CartesianCoords, etc. that serves as the unit-sphere implementation of the coordinates.
This is already used in the code a bit, via coords2cart and cart2coords. My theory is that we can create some <:AbstractSkyCoords type that serves as the base, default representation of all SkyCoords. this means as long as we provide a conversion to this type for each new type, we could allow efficient code reuse using a pretty Julian style of generics with fallbacks and separate optimized code.
This, itself, was part of my features list #30 but i'm starting to see how we can use it to better serve our package in terms of functionality, not just extra features.
The text was updated successfully, but these errors were encountered:
I'm curious of the thoughts of creating a type along the lines of
CartCoords
,UnitCoords
,CartesianCoords
, etc. that serves as the unit-sphere implementation of the coordinates.This is already used in the code a bit, via
coords2cart
andcart2coords
. My theory is that we can create some<:AbstractSkyCoords
type that serves as the base, default representation of all SkyCoords. this means as long as we provide a conversion to this type for each new type, we could allow efficient code reuse using a pretty Julian style of generics with fallbacks and separate optimized code.This, itself, was part of my features list #30 but i'm starting to see how we can use it to better serve our package in terms of functionality, not just extra features.
The text was updated successfully, but these errors were encountered: