new namespaces are
international ( combination of us and imperial + Canada etc)
iau (https://www.iau.org/
imperial ( old imperial units)
typographical ( for sizes of printing fonts etc)
These namespace are based on some research , mainly on wikipedia.
Look in src/include/units/physical/si/length.h to see links to see the references to documentation justifying the change.
Unfortunately there are 3 foot units for example, an old imperial version, an old us version and an international version, which is more recent and attempts to unify the two previous ones. All versions have slight changes in value, so I opted to use the international version
The main change in the layout is that inch,foot and yard have been moved from us to international.
With this modification, I also modified the physical/us/area.hpp, volume.hpp and volume.hpp headers to refer to the international units.
This may not be correct, but if the modified us::foot (rather than international foot is used as a basis for these units, then
there is a ratio integer overflow during compilation, probably due to taking 3rd power of a ratio. After this commit. I will try to show that on another branch.
Add si::density quantity header .
Add si::resistance quantity header.
Update si::capacitance header with mF, uF, nF, pF.
Update si::voltage header with mV, uV, nV,pV
Third party example : add capacitor time curve example
Add incoherent length units, TODO move them out from si header.
Third party examples : add clcpp_response showing effectivenes of typed units for physical quantity library
Third party examples : add conversion factor example
Add third party examples to cmake
Third party examples : box example : Add air_density constant for clarity remove explicit this-> and tidy up.
Third party examples : in clcpp response example, change base unit from km to m for single type or all units example.
Third party examples : conversion_factor , add inline constexpr to units_str function.
Third party examples : box_example, change quantity::unit syntax to quantity::unit<> to allow generic(default double) value_type.
examples : remove examples from third party to main examples directory. Update cmake.
physical/si/resistance.hpp : remove underscores from kiloohm etc, UDL collision with 'R' so prefix with underscore
https://github.com/mpusz/units/issues/14
This "works", as in it passes all static and runtime tests.
However quite a few of the tests have been "modified" to make them pass. Whether
this is legitimate is debatable and should be the source of some thought /
discussion.
1. many of the static tests and some of the runtime tests have had the input
ratios of the tests modified in the following way. eg ratio<3,1000> =>
ratio<3,1,-3>. ie they have been "canonicalised".
There are obviously an infinite number of ratios which represent the same
rational number. The way `ratio` is implemented it always moves as "many powers
of 10" from the `num` and `den` into the `exp` and that makes the `canonical`
ratio.
Because these are all "types" and the lib uses is_same all over the place, only
exact matches will be `is_same`. ie ratio<300,4,0> !is_same ratio<3,4,2> (the
latter is the canonical ratio). This is perhaps fine for tests in the devlopment
phase, but there may be a need for "more forgiving" comparison / concept of
value equality. One such comparison which compares den,num,exp after
canonicalisation is the constexpr function `same` as defined at top of
`ratio_test.cpp`. We may need to expose this and perhaps add even more soft
comparisions.
2. In the runtime tests it is "subjective" how some resukts should be
printed. There is the question of "how exactly to format certain ratios". eg
omit denominators of "1" and exponents of "0". However before even addressing
these in detail a decision needs to be made about the general form of
"non-floating-point-converted" ratios which do not map exactly to a "Symbol
prefix".
Arguably these are "relatively ugly" whatever we do, so we could just
go for an easily canonicalised form. An example is:
- CHECK(stream.str() == "10 [1/60]W");
+ CHECK(stream.str() == "10 [1/6 x 10⁻¹]W");
Which of thses is "better"? Is there a "third", better form? It's not obvious.
My opnion is: Both of 1&2 are fine for now, unless we think they go down the
wrong avenue, and can be "perfected later"? ie we can expose a softer version of
ratio based equality, and decide on canonical way of printing ratios (as far as
that is actually a very useful output form, compared with decimal, scientific or
engineering notation).
rbrugo
Ramzi Sabra
Mateusz Pusz
Andy Little
Oliver Schönrock