I'd like to implement a naive quantities/units library using concepts from Dimensional Analysis in C++ (https://dl.acm.org/doi/10.1145/185009.185036) I'm aware of https://github.com/SciNim/Unchained. Looking to learn my own way in this matter, at least to start.
Specifically, each template/variant/generic parameter is an integer (or rational) of the powers of that dimension. Each dimension such as Mass, Length, or Time has an integer specifying the power. Example: Speed is Length/Time, or Length * Time^-1, so Mass=0, Length=1, Time=-1. Sums and differences should match in their values of L,M,T. Products and divisions should add and subtract the values of L,M,T.
How do I get the integer values of these type parameters?
If I remove the distinct keyword, then junk1 compiles but I then cannot define `$` for each type to return "m" for example, and Quantity[1,0,0] looks the same as Quantity[0,1,0]. etc. So I'm pretty sure these have to be distinct.
I messed around with typetraits and see that I could get 1,0,0 if I could get Quantity[1,0,0] out of Meters, but I'm not sure how to do that.
How do I get `Quantity[1,0,0]` from `Meters`?
Something like:
import std/typetraits
import std/strutils
type
Quantity[L,M,T] = distinct float
Meters = distinct Quantity[1,0,0]
Kilograms = distinct Quantity[0,1,0]
Seconds = distinct Quantity[0,0,1]
Speed = distinct Quantity[1,0,-1]
SomeQuantity = Meters | Kilograms | Seconds | Speed
proc junk1[L,M,T](val: Quantity[L,M,T]): string =
# Trying to get integer values of L,M,T
# Doesn't compile if junk1 is called below.
# Type mismatch expected val to be Quantity not Meters
discard
#proc junk2[T:Quantity[L,M,T]](val: T): string =
# Trying to get integer values of L,M,T
# Doesn't compile at all, even without calling junk2 below.
# Undeclared identifier L
# discard
proc junk3[T:SomeQuantity](val: T): string =
# Compiles, T is Meters or Kilograms
# How do I get the values of L,M,T ?
$T
proc junk4[T:SomeQuantity](val: T) =
echo T.arity # -> 1
echo Meters.arity # -> 1
echo Quantity.arity # -> 4
echo SomeQuantity.arity # -> 4
echo Quantity[1,0,0].arity # -> 5
echo T.distinctBase # -> float
echo Meters.distinctBase # -> float
echo Quantity.distinctBase # -> Quantity
echo SomeQuantity.distinctBase # -> SomeQuantity
echo Quantity[1,0,0].distinctBase # -> float
echo Quantity[1,0,0].genericParams # -> (StaticParam[1], StaticParam[0], StaticParam[0])
echo Quantity[1,0,0].genericParams.get(0) # -> StaticParam[1]
echo Quantity[1,0,0].genericParams.get(1) # -> StaticParam[0]
echo Quantity[1,0,0].genericParams.get(2) # -> StaticParam[0]
echo Quantity[1,0,0].genericParams.get(0).value # -> 1
echo Quantity[1,0,0].genericParams.get(1).value # -> 0
echo Quantity[1,0,0].genericParams.get(2).value # -> 0
echo Quantity[1,0,0].genericParams.get(0).value.typeof # -> int (yay!)
echo Quantity[1,0,0].genericParams.get(1).value.typeof # -> int (yay!)
echo Quantity[1,0,0].genericParams.get(2).value.typeof # -> int (yay!)
let len1 = Meters(10.0)
let mass1 = Kilograms(5.0)
echo junk3(len1) # -> Meters
echo junk3(mass1) # -> Kilograms
junk4(len1) # -> explorations with typetraits
type
Quantity[L,M,T: static int] = distinct float
Meters = Quantity[1,0,0]
Kilograms = Quantity[0,1,0]
Seconds = Quantity[0,0,1]
Speed = Quantity[1,0,-1]
SomeQuantity = Meters | Kilograms | Seconds | Speed
proc junk1[L,M,T: static int](val: Quantity[L,M,T]): string =
$LYou do not want Meters to be a different type from Quantity[1,0,0], so do not use distinct there. And you need to explicitly declare that L,M,T are integers, not types.
While what @xigoi says is fine and perhaps more helpful, I am compelled to observe that much elementary modeling of physical units oversimplifies. Integer exponents for dimensions are a special case for a system of units. The defining case is (at least) rationals (really the physical-dimensional-logarithms form a vector space over the rational field - of arbitrary vector-dimension, with unfortunately two different senses of the word "dimension", never mind ambiguities like "unit vector" - terminology here is NOT easy 🤦 ). The alternative to accepting rationals is to say the CGS system where something as simple as Coulomb's law yields 1/2-integer exponents is invalid or somehow "not a 'system of units'" and making it unrepresentable. While you're at it, you'd also invalidate many systems of "Natural units" typically labeled by which "fundamental" constants are set to 1 & dimensionless. The good news is that import rationals; const x = initRational(1/2) works fine in Nim's VM.
While converting between units "within one system" is simple (much like integers are simple compared to rationals or reals simple compared to complex), converting "across systems" has a "different proc signature" or "I/O" complexity. "Projecting down" from higher to lower dimensional vector spaces largely removes "magic" constants (or makes them 1.0 & unit-dimensionless or affects algebra with sqrt(-1)), while "back projection" requires both knowing the "physical type" (e.g. "area, energy, Re, Im, etc.") and inserting constants back in to expressions (as well as some linear algebra with rationals). Things can get even more complicated trying to "type with units" higher dimensional objects like vectors & matrices, as is covered in a 1995 Springer book by Hart called "Multidimensional Analysis: Algebras and Systems for Science and Engineering". I believe there is a C++ units template library that actually handles this case (but I think dodges unit system conversion).
Alternatively, an object could be used in place of the distinct Quantity.
type
Quantity[L,M,T: static int] = distinct float
Meters = object
data*: Quantity[1,0,0]
Kilograms = object
data*: Quantity[0,1,0]
Seconds = object
data*: Quantity[0,0,1]
Speed = object
data*: Quantity[1,0,-1]
SomeQuantity = Meters | Kilograms | Seconds | Speed
assert Meters isnot Kilograms
echo Meters.data # => Quantity[1, 0, 0]If you are trying to use distinct because of data size, allocation cost, dispatch cost, etc., then object (unless it is a ref object or object of RootObj) is also good because internally it is just a structure.