Commit Graph

16 Commits

Author SHA1 Message Date
Mateusz Pusz
0a906450a2 Custom representation tests moved to a new file 2020-03-24 22:56:11 +01:00
Mateusz Pusz
6a5f25750d UDL naming refactored 2020-03-10 20:53:53 +01:00
Mateusz Pusz
0c89df3980 unknown_unit renamed to unknown_coherent_unit 2020-02-22 09:37:40 +01:00
Mateusz Pusz
18620044c5 All UDLs are now prefixed with q_ 2020-02-17 15:56:06 +01:00
Mateusz Pusz
a01c811f5f Square and cubic UDLs renamed 2020-01-09 10:03:41 +01:00
Oliver Schönrock
509b6c9653 implementing ratio<num,den,exp> which replaces ratio<num,den>
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).
2019-12-28 17:59:47 +01:00
Mateusz Pusz
6596c15238 scaled_unit template parameters order fixed (sorry Oliver) 2019-12-14 21:16:15 +01:00
Mateusz Pusz
b1b63e1b3a 2 parital specializations of a derived_dimension split to different types 2019-12-14 11:44:56 +01:00
Mateusz Pusz
156ab7ae7f Unknown dimension assert added to quantity_test 2019-12-12 15:39:04 +01:00
Mateusz Pusz
f31b26b5e5 Design cleanup
- unknown_unit added
- examples refactored
- base_type renamed to downcast_base_type
- scaled_unit renamed to named_scaled_unit
- detail::reference_unit renamed to scaled_unit
- quantity_test cleanup
2019-12-06 12:18:39 +01:00
Mateusz Pusz
c48bfe2098 quantity refactored and quantity_test enabled 2019-12-04 17:46:19 +01:00
Mateusz Pusz
b9dd6ab440 my_value compilation fixed 2019-11-16 18:29:56 +01:00
Mateusz Pusz
57e464cc99 quantity constraints refactored 2019-11-15 20:20:25 +01:00
Mateusz Pusz
2328a26992 Downcasting support added to quantity_cast (resolves #26) 2019-11-09 14:42:06 +00:00
Mateusz Pusz
367c7d5b6e my_value constructor refactored 2019-11-02 13:58:35 +01:00
Mateusz Pusz
3475f5193e Catch2 support added (resolves #8) 2019-10-14 10:53:02 +02:00