this improves the situation for #55 (doesn't solve it outright)
motivating examples which now work are:
1q_mi * 1q_mi * 1q_mi
1q_au * 1q_au
tests added and docs updated
really finds the maximum common ration as opposed to previous algo which
simplified on the exp part of the ratio by using std::min
most of new code credit to Conor Williams
discussion and additional doc here:
https://github.com/mpusz/units/issues/62#issuecomment-588152833
test case was 1yd + 1in = 37in => added as a test
commenting out unusued ratio_add and its tests
if to be reintroduced, should also use the new gcd routines
additonal change was required to check in `safe_divisible` concept
den=1 is not sufficient anymore. reusing new gcd routines
moved ratio nomalize and new gcd routines into new, separate bits/ratio_maths.h
this resolves#62
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.
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).
