Imperial, US customary and so on have the same dimensions as SI and thus do not need to be considered as separate systems from the perspective of quanstants. All units in those sets can be converted directly to SI. Moreover, there is no clear set of base units in those systems. So it makes sense for base() to return a quantity in SI base units.
The various variants of cgs define different base units, however, and the electrostatic units have inherently different dimensions. Quantities defined in cgs units should return cgs quantities from base(), and an appropriate Dimensions should be used with fewer dimensions (probably a subclass called CGSDimensions).
A cgs module needs to define new cgs base units as well as electromagnetic units for each variant. It should also provide to_si() and from_si() functions, as this is probably preferable to adding a method to all quantities and a "system" property to all units.
Base units of different systems would be unique and therefore not compare equal, so second != cgs_second. This deliberately prevents using quantities defined in different systems together without first converting.
An open question is whether it should be allowed to do arithmetic between quantities from different systems; preventing this would probably mean either adding a "system" property to units after all and slowing things down by checking before every operation, or subclassing Quantity for cgs quantities (tedious for the user). But at the end of the day a CompoundUnit does not care what system its components are, and base() will work indiscriminately, though of course a mixed compound unit will return a mixture of base units from different systems. The results of arithmetic would be fairly nonsensical but that could be left to the user to deal with.
Different cgs systems use different relationships and constants to define the electromagnetic units, so the unit of charge can have different dimensions. However, these units are then unique with different symbols and names, and can still be represented in the same base units. The question is then whether they should be distinct systems or if they may be interoperable. The units of all variants all reduce to the same base units, after all.
It then also needs to be considered how to handle natural (and atomic units will be the same); after all, quantities are inherently dimensionless in those systems, so they could be handled as separate systems with no units (or a single dimensionless natural_units unit akin to the unitless unit) and where everything has dimensions of 0. Conversion would then require the user to specify the desired SI units, dimensions, or quantity type. Alternatively, there could be seven base natural units corresponding to the seven base SI units, but where all seven and also any compound units created from them just have (natural) as their symbol; the dimensions would be tracked as normal, making conversion to SI easier.
There could be yet another config variable to allow/disallow intersystem arithmetic, but every check of the config slows down common operations so I am keen to avoid this.
Imperial, US customary and so on have the same dimensions as SI and thus do not need to be considered as separate systems from the perspective of quanstants. All units in those sets can be converted directly to SI. Moreover, there is no clear set of base units in those systems. So it makes sense for
base()to return a quantity in SI base units.The various variants of cgs define different base units, however, and the electrostatic units have inherently different dimensions. Quantities defined in cgs units should return cgs quantities from
base(), and an appropriateDimensionsshould be used with fewer dimensions (probably a subclass calledCGSDimensions).A cgs module needs to define new cgs base units as well as electromagnetic units for each variant. It should also provide
to_si()andfrom_si()functions, as this is probably preferable to adding a method to all quantities and a "system" property to all units.Base units of different systems would be unique and therefore not compare equal, so
second != cgs_second. This deliberately prevents using quantities defined in different systems together without first converting.An open question is whether it should be allowed to do arithmetic between quantities from different systems; preventing this would probably mean either adding a "system" property to units after all and slowing things down by checking before every operation, or subclassing Quantity for cgs quantities (tedious for the user). But at the end of the day a
CompoundUnitdoes not care what system its components are, andbase()will work indiscriminately, though of course a mixed compound unit will return a mixture of base units from different systems. The results of arithmetic would be fairly nonsensical but that could be left to the user to deal with.Different cgs systems use different relationships and constants to define the electromagnetic units, so the unit of charge can have different dimensions. However, these units are then unique with different symbols and names, and can still be represented in the same base units. The question is then whether they should be distinct systems or if they may be interoperable. The units of all variants all reduce to the same base units, after all.
It then also needs to be considered how to handle natural (and atomic units will be the same); after all, quantities are inherently dimensionless in those systems, so they could be handled as separate systems with no units (or a single dimensionless
natural_unitsunit akin to theunitlessunit) and where everything has dimensions of 0. Conversion would then require the user to specify the desired SI units, dimensions, or quantity type. Alternatively, there could be seven base natural units corresponding to the seven base SI units, but where all seven and also any compound units created from them just have(natural)as their symbol; the dimensions would be tracked as normal, making conversion to SI easier.There could be yet another config variable to allow/disallow intersystem arithmetic, but every check of the config slows down common operations so I am keen to avoid this.