Currently the unxt package vendors a custom Quantity (and related) object as well as a UnitSystem (and related).
The actual units and their conversions are managed by Astropy.
To make unxt a tool for the general ML community it would be ideal to allow the user to choose what units backend to use.
This will require a fair bit of refactoring to decouple unxt from astropy.units. Instead of directly calling astropy functions we will need to develop more generic functions which can then refer to the chosen backend. I think we should lean into multiple dispatch and therefore draw inspiration from Unitful.jl.
I'm envisioning
Dimensions-related API:
AbstractDimensions: a non-init'able base class for all backends to subclass.
AstropyDimensions: wrapper around astropy.units.PhysicalType
...
[x] dimensions: function to create an AbstractDimensions object. like np.array for making np.ndarray. This is multi-dispatched for all the different ways to make a Dimensions object. (#181)
[x] dimensions_of: function to get the dimensions of an object, returning dimensionless if it's not a dimensionful object. (#177)
Dimensions-system-related API:
DimensionSystem
dimensionsystem: function to create an AbstractDimensionsSystem object, making a new subclass if necessary.
dimensionsystem_of: function to get / infer the dimension system of an object.
Units-related API:
AbstractUnits: a non-init'able base class for all backends to subclass. This is a composite units object. Users will never see a lonely singular unit. This ensure that the API is the same, regardless of the backend.
attribute: dimensions
AstropyUnits: wrapper around astropy.units.CompositeUnit
...
[x] units: function to create an AbstractUnits object. This is multi-dispatched for all the different ways to make a Units object. (#175)
[x] units_of: function to get the units of an object, returning dimensionless if it's not a dimensionful object. (#175)
UnitSystem-related API:
[x] AbstractUnitSystem
[x] specific subclasses, e.g. LTMUnitSystem for a length-time-mass only system
[x] unitsystem: function to create an AbstractDimensionsSystem object, making a new subclass if necessary.
[x] unitystem_of: function to get / infer the dimension system of an object. (#170)
Currently the
unxtpackage vendors a customQuantity(and related) object as well as aUnitSystem(and related). The actual units and their conversions are managed by Astropy. To makeunxta tool for the general ML community it would be ideal to allow the user to choose what units backend to use.This will require a fair bit of refactoring to decouple
unxtfromastropy.units. Instead of directly calling astropy functions we will need to develop more generic functions which can then refer to the chosen backend. I think we should lean into multiple dispatch and therefore draw inspiration fromUnitful.jl. I'm envisioningDimensions-related API:
AbstractDimensions: a non-init'able base class for all backends to subclass.AstropyDimensions: wrapper aroundastropy.units.PhysicalTypedimensions: function to create anAbstractDimensionsobject. likenp.arrayfor makingnp.ndarray. This is multi-dispatched for all the different ways to make a Dimensions object. (#181)dimensions_of: function to get the dimensions of an object, returning dimensionless if it's not a dimensionful object. (#177)Dimensions-system-related API:
DimensionSystemdimensionsystem: function to create anAbstractDimensionsSystemobject, making a new subclass if necessary.dimensionsystem_of: function to get / infer the dimension system of an object.Units-related API:
AbstractUnits: a non-init'able base class for all backends to subclass. This is a composite units object. Users will never see a lonely singular unit. This ensure that the API is the same, regardless of the backend.dimensionsAstropyUnits: wrapper aroundastropy.units.CompositeUnitunits: function to create anAbstractUnitsobject. This is multi-dispatched for all the different ways to make a Units object. (#175)units_of: function to get the units of an object, returning dimensionless if it's not a dimensionful object. (#175)UnitSystem-related API:
AbstractUnitSystemLTMUnitSystemfor a length-time-mass only systemunitsystem: function to create anAbstractDimensionsSystemobject, making a new subclass if necessary.unitystem_of: function to get / infer the dimension system of an object. (#170)Quantity-related API:
AbstractQuantity: base class.value: Any.units: AbstractUnitsAbstractParametricQuantity,Quantity,UncheckedQuantity,AbstractDistance,Distance,Parallax,DistanceModulusuconvert: the same API asUnitful.jlfor doing a quantity's unit conversions. (#186)ustrip: the same API asUnitful.jl. (#186)upreferred: the same API asUnitful.jl.Support other plum API.
convertpromotePlanned backend support: