Closed mpusz closed 1 year ago
BTW, the rationale for making an energy a distinct kind is the following quote from the SI Brochure:
In practice, with certain quantities, preference is given to the use of certain special unit names to facilitate the distinction between different quantities having the same dimension. When using this freedom, one may recall the process by which this quantity is defined. For example, the quantity torque is the cross product of a position vector and a force vector. The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit joule), the joule is never used for expressing torque.
So J
should be defined as a quantity only valid for energy kind, the same as we agreed to define Hz
to be used only with a frequency
kind.
Done in V2.
As ISO 80000 states, quantities of the same kind are comparable, addable, and subtractable. With that, we can create kinds of
frequency
,radioactivity
, andmodulation_rate
, where all of them have dimension1 / dim_time
to prevent addition and subtraction on them. So1 * Hz + 1 * Bq + 1 * Bd
will not work.On the other hand, we have several quantities of energy which probably should become a kind as well. Especially since there is no way to explicitly derive one definition from another as, for example,
kinetic_energy
is defined asm V²/2
. However, this means that the following will not compile:because the rhs is a quantity of
isq::mass * isq::length² / isq::time²
rather thanisq::energy
kind.In order to make it compile, we will have to explicitly convert the rhs of addition to an energy quantity with something like:
Also, please note that most probably:
will work without any explicit conversion because, at least as of now, for interconvertibility, we check interconvertibility of the ingredient quantities and ignore kinds.
One possible way is to acknowledge a hierarchy of kinds so
isq::kinetic_energy(85 * kg * pow<2>(2 * m / s) / 2)
is both of theisq::energy
andisq::mass * isq::length² / isq::time²
kinds rather than just ofisq::energy
kind. This, however, would make this work1 * Hz + 1 * Bq + 1 * Bd
, and the result would be of1 / isq::time
kind. Even worse, the following would also work:Does it make any sense at all? Do you have any ideas on how to improve here? Maybe we should not try to provide any type-safety for kinds at all, but then the following would work, which bothers me a lot: