2018-08-22 12:11:19 +02:00
|
|
|
// The MIT License (MIT)
|
|
|
|
//
|
|
|
|
// Copyright (c) 2018 Mateusz Pusz
|
|
|
|
//
|
|
|
|
// Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
// of this software and associated documentation files (the "Software"), to deal
|
|
|
|
// in the Software without restriction, including without limitation the rights
|
|
|
|
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
// copies of the Software, and to permit persons to whom the Software is
|
|
|
|
// furnished to do so, subject to the following conditions:
|
|
|
|
//
|
|
|
|
// The above copyright notice and this permission notice shall be included in all
|
|
|
|
// copies or substantial portions of the Software.
|
|
|
|
//
|
|
|
|
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
// SOFTWARE.
|
|
|
|
|
2019-12-01 19:47:58 +01:00
|
|
|
#include "units/unit.h"
|
|
|
|
#include "units/physical/si/prefixes.h"
|
2018-08-22 12:11:19 +02:00
|
|
|
|
2018-09-28 07:47:37 -07:00
|
|
|
namespace {
|
2019-04-09 17:22:15 +02:00
|
|
|
|
2019-12-01 19:47:58 +01:00
|
|
|
using namespace units;
|
2019-07-24 11:58:15 +02:00
|
|
|
|
2019-12-01 19:47:58 +01:00
|
|
|
struct metre : named_unit<metre, "m", si::prefix> {};
|
|
|
|
struct centimetre : prefixed_unit<centimetre, si::centi, metre> {};
|
|
|
|
struct kilometre : prefixed_unit<kilometre, si::kilo, metre> {};
|
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-27 18:49:43 +00:00
|
|
|
struct yard : named_scaled_unit<yard, "yd", no_prefix, ratio<9'144, 1, -4>, metre> {};
|
2019-12-06 12:18:39 +01:00
|
|
|
struct foot : named_scaled_unit<foot, "ft", no_prefix, ratio<1, 3>, yard> {};
|
2019-12-01 19:47:58 +01:00
|
|
|
struct dim_length : base_dimension<"length", metre> {};
|
2019-07-24 16:55:21 +02:00
|
|
|
|
2019-12-01 19:47:58 +01:00
|
|
|
struct second : named_unit<second, "s", si::prefix> {};
|
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-27 18:49:43 +00:00
|
|
|
struct hour : named_scaled_unit<hour, "h", no_prefix, ratio<36, 1, 2>, second> {};
|
2019-12-01 19:47:58 +01:00
|
|
|
struct dim_time : base_dimension<"time", second> {};
|
2019-07-24 16:55:21 +02:00
|
|
|
|
2019-12-07 16:30:40 +01:00
|
|
|
struct kelvin : named_unit<kelvin, "K", no_prefix> {};
|
|
|
|
// struct kilokelvin : prefixed_unit<kilokelvin, si::kilo, kelvin> {}; // should not compile (prefix not allowed for this reference unit)
|
|
|
|
|
2019-12-01 19:47:58 +01:00
|
|
|
struct metre_per_second : unit<metre_per_second> {};
|
|
|
|
struct dim_velocity : derived_dimension<dim_velocity, metre_per_second, exp<dim_length, 1>, exp<dim_time, -1>> {};
|
|
|
|
struct kilometre_per_hour : deduced_unit<kilometre_per_hour, dim_velocity, kilometre, hour> {};
|
2019-11-04 06:46:53 +00:00
|
|
|
|
2019-12-14 21:16:15 +01:00
|
|
|
static_assert(std::is_same_v<downcast<scaled_unit<ratio<1>, metre>>, metre>);
|
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-27 18:49:43 +00:00
|
|
|
static_assert(std::is_same_v<downcast<scaled_unit<ratio<1, 1, -2>, metre>>, centimetre>);
|
|
|
|
static_assert(std::is_same_v<downcast<scaled_unit<ratio<yard::ratio::num, yard::ratio::den, yard::ratio::exp>, metre>>, yard>);
|
2019-12-14 21:16:15 +01:00
|
|
|
static_assert(std::is_same_v<downcast<scaled_unit<ratio_multiply<typename yard::ratio, ratio<1, 3>>, metre>>, foot>);
|
|
|
|
static_assert(std::is_same_v<downcast<scaled_unit<ratio_divide<typename kilometre::ratio, typename hour::ratio>, metre_per_second>>, kilometre_per_hour>);
|
2019-11-04 06:46:53 +00:00
|
|
|
|
2019-12-01 19:47:58 +01:00
|
|
|
static_assert(centimetre::symbol == "cm");
|
|
|
|
static_assert(kilometre::symbol == "km");
|
2019-12-11 08:07:13 +01:00
|
|
|
static_assert(kilometre_per_hour::symbol == "km/h");
|
2019-11-04 06:46:53 +00:00
|
|
|
|
2018-09-28 07:47:37 -07:00
|
|
|
} // namespace
|