Commit Graph
136 Commits
Author SHA1 Message Date
Mateusz Pusz 6539b492a3 fix: std::chrono::duration support fixed
Resolves #198
2021-01-04 13:05:26 +01:00
Johel Ernesto Guerrero Peña 5c6cd1b26b fix: parameter constness in constraints 2021-01-03 19:17:43 +01:00
Mateusz Pusz 32391866be refactor: Limited the equivalent trait usage 2020-12-28 18:40:58 +01:00
Mateusz Pusz 55e5cac33f refactor: More stream-specific implementation moved to quantity_io.h 2020-12-28 16:15:19 +01:00
Mateusz Pusz cff718301c refactor: quantity_io added 2020-12-28 15:18:36 +01:00
Mateusz Pusz 0fb821a392 fix: Commutativity no longer required for operator*
Resolves #185
2020-12-27 12:26:40 +01:00
Mateusz Pusz 68058cfb25 fix: Atomic constraints fixed for safe_convertible_to_ 2020-12-22 14:37:03 +01:00
Mateusz Pusz d64d26a4c4 refactor: interoperability with quantity-like types simplified
Type trait specialization for each `quantity` type is not needed anymore.

Relates to #33.
2020-10-07 14:29:12 +02:00
Mateusz Pusz 2dd8c90250 feat: ✨ interoperability with std::chrono::duration and other units libraries
Resolves #33
2020-10-07 12:02:08 +02:00
Mateusz Pusz cfc90f4aac refactor: 💥 basic_concepts, quantity and quantity_cast refactored
BREAKING CHANGE:  ScalableNumber renamed to QuantityValue

Resolves #107
2020-10-06 18:17:52 +02:00
Mateusz Pusz 920c396742 feat: value initialization for quantity value removed (left with a default initialization) 2020-09-24 16:10:07 +02:00
Mateusz Pusz a098f97c08 feat: CTAD for dimensionless quantity added 2020-09-23 16:34:13 +02:00
Mateusz Pusz cb86cd2bcd fix: regression in quantity::op<<() for the case of std::setw() fixed 2020-09-15 08:55:35 +02:00
Mateusz Pusz 8687527b34 perf: temporary string creation removed from quantity::op<<() 2020-09-15 07:30:06 +02:00
Mateusz Pusz ca11f4ff5d fix: ms-gsl Expects commented out for runtime code
Refers to #165

Resolves #164
2020-09-14 20:09:51 +02:00
Mateusz Pusz 2a56438f1c refactor: file tree with systems defninitions refactored to limit ODR issues
Relates to #32 as with this commit we created something like modules for derived quantities
2020-09-11 18:11:25 +02:00
Mateusz Pusz 6f88a03285 fix: ambiguity of operators in case of unknown_dimension resolved 2020-09-10 13:02:33 +02:00
Mateusz Pusz 44e8d39102 feat: dimensionless quantity implicit construction enabled for DOWNCAST_MODE=OFF 2020-09-10 11:34:58 +02:00
Mateusz Pusz e367afed71 Merge branch 'downcasting_2.0' 2020-09-09 20:31:03 +02:00
Mateusz Pusz 3e9d5ca189 refactor: ♻️ unitless renamed to one
Resolves #27
2020-09-09 11:20:55 +02:00
Mateusz Pusz 5d62dda479 refactor: non-zero contracts check in quantity improved
Thanks @johelegp!
2020-09-08 22:55:41 +02:00
Mateusz Pusz 9a49df7222 refactor: 💥 Scalar concept renamed to ScalableNumber
Resolves #114
2020-09-08 21:17:09 +02:00
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 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
Mateusz Pusz b318e8d039 VS2019 support added 2020-09-04 23:06:57 +02:00
Mateusz Pusz 51ffbadf74 gcc-9.3 compilation fixed 2020-09-04 22:11:24 +02:00
Mateusz Pusz 5c98924efb Downcasting reworked to allow OFF and AUTO modes 2020-08-19 13:37:57 +02:00
Mateusz Pusz deb1ee6efa Truncating conversions disalowed for *=, /=, +=, amd -= operators (resolves #137) 2020-08-16 13:29:40 +02:00
Johel Ernesto Guerrero Peña 69dddaf1f6 feat: nodiscard for postfix increment and decrement 2020-08-16 12:32:56 +02:00
Mateusz Pusz d171f5451e NTTP ratio support added (resolves #49) 2020-06-27 19:15:46 +02:00
Mateusz Pusz 0c0d097586 C++20 comparison operators refactored 2020-06-19 19:37:18 +02:00
Mateusz Pusz fea072aeb5 warnings.cmake refactored 2020-05-29 10:07:01 +02:00
Mateusz Pusz 5dd9eaac87 Redundant constraints removed (resolves #109) 2020-05-24 22:49:53 +02:00
Mateusz Pusz d19825e14c Numeric concepts removed from repo (no longer used) 2020-03-28 12:08:37 +01:00
Mateusz Pusz ab1cc4b8e7 Overconstrained quantity operations relaxed 2020-03-25 15:04:33 +01:00
Mateusz Pusz c33f6f2d59 ostream width, align and fill added 2020-03-19 09:23:27 +01:00
Mateusz Pusz 1f63fdb945 Printing of a space separator for unitless quantites disabled 2020-02-24 20:01:57 +01:00
Oliver Schönrock 39a2c2de0e employing more mathemtaically correct ratio_gcd calc (for common ratio)
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
2020-02-20 19:59:12 +01:00
Mateusz Pusz 3be8ee921e Starship improvements after the latest gcc fixes 2020-02-12 09:48:04 +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 0ad78fe753 small changes based on code review 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 3decaecb52 TODO comments clean-up 2019-12-17 20:15:38 +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
Mateusz Pusz 9d50ea6ab5 CGS case added to avg_speed example 2019-12-11 21:38:44 +01:00
Mateusz Pusz 71f38222ea Implicit conversions fixed 2019-12-11 16:16:05 +01:00
Mateusz Pusz 5a7324596d Resulting unit ratio fixed in arithmetic operations 2019-12-11 13:31:40 +01:00