Commit Graph
24 Commits
Author SHA1 Message Date
Mateusz Pusz 4bb51586dc refactor: got rid of gcc-9 backlog
BREAKING CHANGE: gcc-9.3 no longer supported
2020-09-08 13:09:34 +02:00
Mateusz Pusz 563b358d5e feat!: 💥 dimensionless quantities refactored
Dimensionless quantities are now represented by quantity types rather
than by plain representation types. Only dimensionless quantities with
`unitless` unit are implicitly convertible from representation types.

`units::exp()` now is a function doing std::exp() on a representation
type (previous `units::exp` class template was renamed to
`units::exponent`).

BREAKING_CHANGE: gcc-9.3 support removed
BREAKING_CHANGE: `exp` and `Exp` renamed to `exponent` and `Exponent`
Resolves #27
Resolves #42
2020-09-08 11:02:16 +02:00
Mateusz Pusz 00cb2cd6c3 refactor: cast_ratio now uses quantity_ratio 2020-09-07 11:11:12 +02:00
Johel Ernesto Guerrero Peña 46761ea2f7 refactor: *_instantation_of to *_specialization_of 2020-09-06 22:52:01 +02:00
Johel Ernesto Guerrero Peña ca1867c9b2 refactor!: pow functions as detail 2020-09-06 09:45:24 +02:00
Johel Ernesto Guerrero Peña 2f5be094b2 refactor: pow10 functions to pow.h 2020-09-06 09:45:24 +02:00
Johel Ernesto Guerrero Peña 40fb1e1e8b fix: iwyu 2020-09-06 09:45:24 +02:00
Mateusz Pusz b318e8d039 VS2019 support added 2020-09-04 23:06:57 +02:00
Mateusz Pusz 7eccef78a9 is_instantiation renamed to is_instantiation_of 2020-06-29 20:28:10 +02:00
Mateusz Pusz d171f5451e NTTP ratio support added (resolves #49) 2020-06-27 19:15:46 +02:00
Johel Ernesto Guerrero Peña 628ccde5f0 fix: use trailing requires clause 2020-06-17 15:31:22 +02:00
Johel Ernesto Guerrero Peña 75119eef3f feat: quantity_point 2020-06-17 15:31:22 +02:00
Mateusz Pusz fea072aeb5 warnings.cmake refactored 2020-05-29 10:07:01 +02:00
Mateusz Pusz 7e935a4108 Physical units put in the physical namespace (I am sorry) 2020-05-08 22:39:24 +02:00
Mateusz Pusz ecb158eaa7 Concepts enabled for customization points 2020-03-26 16:37:47 +01:00
Mateusz Pusz ce0fbfa0a1 quantity cast refactored to match new ratio and Scalar design 2020-03-25 22:07:16 +01:00
Mateusz Pusz ab1cc4b8e7 Overconstrained quantity operations relaxed 2020-03-25 15:04:33 +01:00
Oliver Schönrock d4492524d1 use assert. static can't work 2020-02-23 17:29:28 +01:00
Mateusz Pusz 18620044c5 All UDLs are now prefixed with q_ 2020-02-17 15:56:06 +01:00
Mateusz Pusz 645570ff57 Library updated to the latest cmake common tools 2020-01-31 17:02:27 +01:00
Oliver Schönrock 23d44c1b4a implementing our own (very limited) std::pow functions
integer and float treated separately
perhaps not ideal, but not obvioius what would be clearly better
2019-12-28 17:59:47 +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 e10f5baab6 Quantity cast for dimension now uses dimension's coherent unit 2019-12-12 15:38:21 +01:00
Mateusz Pusz fbf3ef8c4f Most of concepts moved to a new file + quantity.h split to smaller pieces 2019-12-12 13:17:31 +01:00