2019-10-16 17:04:41 +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-29 17:06:03 +01:00
|
|
|
|
#include "units/physical/cgs/length.h"
|
|
|
|
|
#include "units/physical/cgs/mass.h"
|
2019-12-11 08:07:13 +01:00
|
|
|
|
#include "units/physical/si/area.h"
|
|
|
|
|
#include "units/physical/si/frequency.h"
|
|
|
|
|
#include "units/physical/si/power.h"
|
|
|
|
|
#include "units/physical/si/pressure.h"
|
|
|
|
|
#include "units/physical/si/velocity.h"
|
|
|
|
|
#include "units/physical/si/volume.h"
|
|
|
|
|
#include "units/physical/si/surface_tension.h"
|
2019-10-18 23:50:43 +02:00
|
|
|
|
#include "units/format.h"
|
2019-10-16 17:04:41 +02:00
|
|
|
|
#include "units/math.h"
|
|
|
|
|
#include <catch2/catch.hpp>
|
|
|
|
|
#include <sstream>
|
|
|
|
|
|
|
|
|
|
using namespace units;
|
2019-12-11 08:07:13 +01:00
|
|
|
|
using namespace units::si;
|
2019-11-06 16:50:34 +00:00
|
|
|
|
using namespace Catch::Matchers;
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
TEST_CASE("operator<< on a quantity", "[text][ostream][fmt]")
|
2019-10-16 17:04:41 +02:00
|
|
|
|
{
|
|
|
|
|
std::stringstream stream;
|
|
|
|
|
|
|
|
|
|
SECTION("quantity with a predefined unit")
|
|
|
|
|
{
|
|
|
|
|
SECTION("integral representation")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 60q_W;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "60 W");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("floating-point representation")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 1023.5q_Pa;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "1023.5 Pa");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
}
|
2019-10-18 15:34:46 +02:00
|
|
|
|
|
2019-11-09 21:01:37 +00:00
|
|
|
|
SECTION("quantity with a predefined prefixed unit")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 125q_us;
|
2019-11-09 21:01:37 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "125 µs");
|
2019-11-09 21:01:37 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-09 21:01:37 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-09 21:01:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-04 06:37:50 +00:00
|
|
|
|
SECTION("quantity with a predefined unit + prefix")
|
|
|
|
|
{
|
|
|
|
|
SECTION("in terms of base units")
|
2019-10-18 15:34:46 +02:00
|
|
|
|
{
|
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
|
|
|
|
const length<scaled_unit<ratio<1, 1, 6>, metre>> q(123);
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "123 Mm");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 15:34:46 +02:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
|
|
|
|
|
SECTION("in terms of derived units")
|
|
|
|
|
{
|
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
|
|
|
|
const energy<scaled_unit<ratio<1, 1, -2>, joule>> q(60);
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "60 cJ");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("quantity with a deduced unit")
|
|
|
|
|
{
|
|
|
|
|
SECTION("coherent derived unit")
|
|
|
|
|
{
|
|
|
|
|
SECTION("acceleration")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 20q_m / 2q_s / 1q_s;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "10 m/s²");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("volume")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 2q_m * 1q_m * 1q_m;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "2 m³");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
2019-11-10 19:51:25 +01:00
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-10 19:51:25 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("surface tension")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 20q_N / 2q_m;
|
2019-11-10 19:51:25 +01:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "10 N/m");
|
2019-11-10 19:51:25 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-10 19:51:25 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
2019-11-05 20:05:11 +00:00
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("deduced derived unit")
|
|
|
|
|
{
|
|
|
|
|
SECTION("velocity")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 20q_km / 2q_h;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "10 km/h");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
}
|
2019-11-04 06:46:53 +00:00
|
|
|
|
|
|
|
|
|
SECTION("surface tension")
|
|
|
|
|
{
|
2019-12-11 08:07:13 +01:00
|
|
|
|
struct newton_per_centimetre : deduced_unit<newton_per_centimetre, dim_surface_tension, newton, centimetre> {};
|
|
|
|
|
const surface_tension<newton_per_centimetre> q(123);
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "123 N/cm");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-11-04 06:46:53 +00:00
|
|
|
|
}
|
2019-11-04 06:37:50 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("quantity with a predefined dimension but unknown unit")
|
|
|
|
|
{
|
2019-10-17 10:16:44 +02:00
|
|
|
|
SECTION("unit::ratio as an SI prefix for a dimension with a special symbol")
|
2019-10-16 17:04:41 +02:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 4q_N * 2q_cm;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "8 cJ");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("unit::ratio for a dimension without a special symbol")
|
2019-10-16 17:04:41 +02:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 2q_cm * 2q_m * 2q_m;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "8 × 10⁻² m³");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("unit::ratio::num != 1 && unit::ratio::den == 1")
|
2019-10-16 17:04:41 +02:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 4 * 2q_min / (2q_s * 2q_s);
|
2019-11-05 20:05:11 +00:00
|
|
|
|
stream << q;
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "2 [6 × 10¹] Hz");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("unit::ratio::num == 1 && unit::ratio::den != 1")
|
2019-10-18 23:50:43 +02:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 20q_J / 2q_min;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "10 [1/6 × 10⁻¹] W");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("unit::ratio::num != 1 && unit::ratio::den != 1")
|
2019-10-18 23:50:43 +02:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 60q_kJ / 2q_min;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "30 [1/6 × 10²] W");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
|
2019-11-05 20:05:11 +00:00
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("quantity with an unkown dimension")
|
|
|
|
|
{
|
|
|
|
|
SECTION("unit::ratio::num == 1 && unit::ratio::den == 1")
|
|
|
|
|
{
|
2019-12-29 17:06:03 +01:00
|
|
|
|
SECTION("SI base units")
|
2019-11-05 20:05:11 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 2q_s * 2q_m * 2q_kg;
|
2019-12-29 17:06:03 +01:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
2019-12-29 17:06:03 +01:00
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
|
|
|
|
CHECK(stream.str() == "8 m⋅kg⋅s");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
|
|
|
|
}
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
2019-12-29 17:06:03 +01:00
|
|
|
|
SECTION("CGS base units")
|
2019-11-05 20:05:11 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 2q_s * cgs::length<cgs::centimetre>(2) * cgs::mass<cgs::gram>(2);
|
2019-12-29 17:06:03 +01:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
|
|
|
|
CHECK(stream.str() == "8 cm⋅g⋅s");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
|
|
|
|
}
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("unit::ratio as an SI prefix")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 4q_km * 2q_s;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "8 × 10³ m⋅s");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("unit::ratio::num != 1 && unit::ratio::den == 1")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 4q_kg * 2q_min / (2q_s * 2q_s);
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "2 [6 × 10¹] kg/s");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("unit::ratio::num == 1 && unit::ratio::den != 1")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 20q_kg / 2q_min;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "10 [1/6 × 10⁻¹] kg/s");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
2019-12-29 17:06:03 +01:00
|
|
|
|
SECTION("CGS base units")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 2q_s * cgs::length<si::metre>(2) * cgs::mass<si::kilogram>(2);
|
2019-12-29 17:06:03 +01:00
|
|
|
|
stream << q;
|
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "8 × 10⁵ cm⋅g⋅s");
|
2019-12-29 17:06:03 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-18 23:50:43 +02:00
|
|
|
|
SECTION("unit::ratio::num != 1 && unit::ratio::den != 1")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 60q_min / 2q_km;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-12-29 17:19:55 +01:00
|
|
|
|
CHECK(stream.str() == "30 [6 × 10⁻²] 1/m⋅s");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("exp::num == 1 && exp::den == 1")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 4q_m * 2q_s;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "8 m⋅s");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("exp::num == 2 && exp::den == 1 for positive exponent")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 4q_m * 2q_s * 2q_s;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "16 m⋅s²");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("exp::num == 2 && exp::den == 1 for negative exponent (first dimension)")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 8q_s / 2q_m / 2q_m;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "2 1/m²⋅s");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("exp::num == 2 && exp::den == 1 for negative exponent (not first dimension)")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 8q_m / 2q_kg / 2q_kg;
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "2 m/kg²");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fractional positive exponent")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = sqrt(9q_m);
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "3 m^(1/2)");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fractional negative exponent")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = sqrt(9 / 1q_m);
|
2019-10-18 23:50:43 +02:00
|
|
|
|
stream << q;
|
2019-11-05 20:05:11 +00:00
|
|
|
|
|
|
|
|
|
SECTION("iostream")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(stream.str() == "3 1/m^(1/2)");
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with default format {} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("fmt with format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q %q}", q) == stream.str());
|
2019-11-05 20:05:11 +00:00
|
|
|
|
}
|
2019-10-18 23:50:43 +02:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-10-16 17:04:41 +02:00
|
|
|
|
|
2019-11-06 16:50:34 +00:00
|
|
|
|
TEST_CASE("format string with only %Q should print quantity value only", "[text][fmt]")
|
|
|
|
|
{
|
|
|
|
|
SECTION("integral representation")
|
|
|
|
|
{
|
2019-11-06 22:45:45 +00:00
|
|
|
|
SECTION("positive value")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", 123q_kmph) == "123");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("negative value")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", 5q_m - 10q_m) == "-5");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("floating-point representation")
|
|
|
|
|
{
|
2019-11-06 22:45:45 +00:00
|
|
|
|
SECTION("positive value")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", 221.q_km / 2q_h) == "110.5");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
2019-11-06 22:45:45 +00:00
|
|
|
|
|
|
|
|
|
SECTION("negative value")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", 3.14q_m - 10q_m) == "-6.86");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("nan")
|
|
|
|
|
{
|
2019-12-11 08:07:13 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", length<metre>(std::numeric_limits<double>::quiet_NaN())) == "nan");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("inf")
|
|
|
|
|
{
|
2019-12-11 08:07:13 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", length<metre>(std::numeric_limits<double>::infinity())) == "inf");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("-inf")
|
|
|
|
|
{
|
2019-12-11 08:07:13 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q}", length<metre>(-std::numeric_limits<double>::infinity())) == "-inf");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST_CASE("format string with only %q should print quantity unit symbol only", "[text][fmt]")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%q}", 123q_kmph) == "km/h");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST_CASE("%q an %Q can be put anywhere in a format string", "[text][fmt]")
|
|
|
|
|
{
|
|
|
|
|
SECTION("no space")
|
|
|
|
|
{
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(fmt::format("{:%Q%q}", 123q_kmph) == "123km/h");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("separator")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q###%q}", 123q_kmph) == "123###km/h");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("opposite order")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%q %Q}", 123q_kmph) == "km/h 123");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
2019-11-06 21:52:48 +00:00
|
|
|
|
|
|
|
|
|
SECTION("tabulator")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q%t%q}", 123q_kmph) == "123\tkm/h");
|
2019-11-06 21:52:48 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("new line")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q%n%q}", 123q_kmph) == "123\nkm/h");
|
2019-11-06 21:52:48 +00:00
|
|
|
|
}
|
2019-11-06 22:45:45 +00:00
|
|
|
|
|
|
|
|
|
SECTION("% sign")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:%Q%% %q}", 123q_kmph) == "123% km/h");
|
2019-11-06 22:45:45 +00:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
2019-11-12 16:55:11 +01:00
|
|
|
|
TEST_CASE("fill and align specification", "[text][fmt]")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
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
|
|
|
|
SECTION("default format {} on a quantity")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("|{:0}|", 123q_m) == "|123 m|");
|
|
|
|
|
CHECK(fmt::format("|{:10}|", 123q_m) == "| 123 m|");
|
|
|
|
|
CHECK(fmt::format("|{:<10}|", 123q_m) == "|123 m |");
|
|
|
|
|
CHECK(fmt::format("|{:>10}|", 123q_m) == "| 123 m|");
|
|
|
|
|
CHECK(fmt::format("|{:^10}|", 123q_m) == "| 123 m |");
|
|
|
|
|
CHECK(fmt::format("|{:*<10}|", 123q_m) == "|123 m*****|");
|
|
|
|
|
CHECK(fmt::format("|{:*>10}|", 123q_m) == "|*****123 m|");
|
|
|
|
|
CHECK(fmt::format("|{:*^10}|", 123q_m) == "|**123 m***|");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
2019-11-12 16:55:11 +01:00
|
|
|
|
SECTION("full format {:%Q %q} on a quantity")
|
|
|
|
|
{
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(fmt::format("|{:0%Q%q}|", 123q_m) == "|123m|");
|
|
|
|
|
CHECK(fmt::format("|{:10%Q%q}|", 123q_m) == "| 123m|");
|
|
|
|
|
CHECK(fmt::format("|{:<10%Q%q}|", 123q_m) == "|123m |");
|
|
|
|
|
CHECK(fmt::format("|{:>10%Q%q}|", 123q_m) == "| 123m|");
|
|
|
|
|
CHECK(fmt::format("|{:^10%Q%q}|", 123q_m) == "| 123m |");
|
|
|
|
|
CHECK(fmt::format("|{:*<10%Q%q}|", 123q_m) == "|123m******|");
|
|
|
|
|
CHECK(fmt::format("|{:*>10%Q%q}|", 123q_m) == "|******123m|");
|
|
|
|
|
CHECK(fmt::format("|{:*^10%Q%q}|", 123q_m) == "|***123m***|");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
|
SECTION("value only format {:%Q} on a quantity")
|
2019-11-12 16:55:11 +01:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("|{:0%Q}|", 123q_m) == "|123|");
|
|
|
|
|
CHECK(fmt::format("|{:10%Q}|", 123q_m) == "| 123|");
|
|
|
|
|
CHECK(fmt::format("|{:<10%Q}|", 123q_m) == "|123 |");
|
|
|
|
|
CHECK(fmt::format("|{:>10%Q}|", 123q_m) == "| 123|");
|
|
|
|
|
CHECK(fmt::format("|{:^10%Q}|", 123q_m) == "| 123 |");
|
|
|
|
|
CHECK(fmt::format("|{:*<10%Q}|", 123q_m) == "|123*******|");
|
|
|
|
|
CHECK(fmt::format("|{:*>10%Q}|", 123q_m) == "|*******123|");
|
|
|
|
|
CHECK(fmt::format("|{:*^10%Q}|", 123q_m) == "|***123****|");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
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
|
|
|
|
SECTION("symbol only format {:%q} on a quantity")
|
2019-11-12 16:55:11 +01:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("|{:0%q}|", 123q_m) == "|m|");
|
|
|
|
|
CHECK(fmt::format("|{:10%q}|", 123q_m) == "|m |");
|
|
|
|
|
CHECK(fmt::format("|{:<10%q}|", 123q_m) == "|m |");
|
|
|
|
|
CHECK(fmt::format("|{:>10%q}|", 123q_m) == "| m|");
|
|
|
|
|
CHECK(fmt::format("|{:^10%q}|", 123q_m) == "| m |");
|
|
|
|
|
CHECK(fmt::format("|{:*<10%q}|", 123q_m) == "|m*********|");
|
|
|
|
|
CHECK(fmt::format("|{:*>10%q}|", 123q_m) == "|*********m|");
|
|
|
|
|
CHECK(fmt::format("|{:*^10%q}|", 123q_m) == "|****m*****|");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
2019-11-12 16:55:11 +01:00
|
|
|
|
TEST_CASE("sign specification", "[text][fmt]")
|
|
|
|
|
{
|
2019-12-11 08:07:13 +01:00
|
|
|
|
length<metre> inf(std::numeric_limits<double>::infinity());
|
|
|
|
|
length<metre> nan(std::numeric_limits<double>::quiet_NaN());
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
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
|
|
|
|
SECTION("default format {} on a quantity")
|
2019-11-12 16:55:11 +01:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{0:},{0:+},{0:-},{0: }", 1q_m) == "1 m,+1 m,1 m, 1 m");
|
|
|
|
|
CHECK(fmt::format("{0:},{0:+},{0:-},{0: }", -1q_m) == "-1 m,-1 m,-1 m,-1 m");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
CHECK(fmt::format("{0:},{0:+},{0:-},{0: }", inf) == "inf m,+inf m,inf m, inf m");
|
|
|
|
|
CHECK(fmt::format("{0:},{0:+},{0:-},{0: }", nan) == "nan m,+nan m,nan m, nan m");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
SECTION("full format {:%Q %q} on a quantity")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(fmt::format("{0:%Q%q},{0:+%Q%q},{0:-%Q%q},{0: %Q%q}", 1q_m) == "1m,+1m,1m, 1m");
|
|
|
|
|
CHECK(fmt::format("{0:%Q%q},{0:+%Q%q},{0:-%Q%q},{0: %Q%q}", -1q_m) == "-1m,-1m,-1m,-1m");
|
2019-11-12 19:46:15 +01:00
|
|
|
|
CHECK(fmt::format("{0:%Q%q},{0:+%Q%q},{0:-%Q%q},{0: %Q%q}", inf) == "infm,+infm,infm, infm");
|
|
|
|
|
CHECK(fmt::format("{0:%Q%q},{0:+%Q%q},{0:-%Q%q},{0: %Q%q}", nan) == "nanm,+nanm,nanm, nanm");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
SECTION("value only format {:%Q} on a quantity")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{0:%Q},{0:+%Q},{0:-%Q},{0: %Q}", 1q_m) == "1,+1,1, 1");
|
|
|
|
|
CHECK(fmt::format("{0:%Q},{0:+%Q},{0:-%Q},{0: %Q}", -1q_m) == "-1,-1,-1,-1");
|
2019-11-12 19:46:15 +01:00
|
|
|
|
CHECK(fmt::format("{0:%Q},{0:+%Q},{0:-%Q},{0: %Q}", inf) == "inf,+inf,inf, inf");
|
|
|
|
|
CHECK(fmt::format("{0:%Q},{0:+%Q},{0:-%Q},{0: %Q}", nan) == "nan,+nan,nan, nan");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
2019-11-12 16:55:11 +01:00
|
|
|
|
TEST_CASE("sign specification for unit only", "[text][fmt][exception]")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK_THROWS_MATCHES(fmt::format("{:+%q}", 1q_m), fmt::format_error, Message("sign not allowed for a quantity unit"));
|
|
|
|
|
CHECK_THROWS_MATCHES(fmt::format("{:-%q}", 1q_m), fmt::format_error, Message("sign not allowed for a quantity unit"));
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
|
|
|
|
|
2019-11-12 16:55:11 +01:00
|
|
|
|
TEST_CASE("precision specification", "[text][fmt]")
|
|
|
|
|
{
|
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
|
|
|
|
SECTION("default format {} on a quantity")
|
2019-11-12 16:55:11 +01:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:.1}", 1.2345q_m) == "1.2 m");
|
|
|
|
|
CHECK(fmt::format("{:.0}", 1.2345q_m) == "1 m");
|
|
|
|
|
CHECK(fmt::format("{:.2}", 1.2345q_m) == "1.23 m");
|
|
|
|
|
CHECK(fmt::format("{:.3}", 1.2345q_m) == "1.235 m");
|
|
|
|
|
CHECK(fmt::format("{:.4}", 1.2345q_m) == "1.2345 m");
|
|
|
|
|
CHECK(fmt::format("{:.5}", 1.2345q_m) == "1.23450 m");
|
|
|
|
|
CHECK(fmt::format("{:.10}", 1.2345q_m) == "1.2345000000 m");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
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
|
|
|
|
SECTION("full format {:%Q %q} on a quantity")
|
2019-11-12 16:55:11 +01:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:.0%Q %q}", 1.2345q_m) == "1 m");
|
|
|
|
|
CHECK(fmt::format("{:.1%Q %q}", 1.2345q_m) == "1.2 m");
|
|
|
|
|
CHECK(fmt::format("{:.2%Q %q}", 1.2345q_m) == "1.23 m");
|
|
|
|
|
CHECK(fmt::format("{:.3%Q %q}", 1.2345q_m) == "1.235 m");
|
|
|
|
|
CHECK(fmt::format("{:.4%Q %q}", 1.2345q_m) == "1.2345 m");
|
|
|
|
|
CHECK(fmt::format("{:.5%Q %q}", 1.2345q_m) == "1.23450 m");
|
|
|
|
|
CHECK(fmt::format("{:.10%Q %q}", 1.2345q_m) == "1.2345000000 m");
|
2019-11-12 16:55:11 +01:00
|
|
|
|
}
|
2019-11-06 16:50:34 +00:00
|
|
|
|
|
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
|
|
|
|
SECTION("value only format {:%Q} on a quantity")
|
2019-11-12 16:55:11 +01:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
CHECK(fmt::format("{:.0%Q}", 1.2345q_m) == "1");
|
|
|
|
|
CHECK(fmt::format("{:.1%Q}", 1.2345q_m) == "1.2");
|
|
|
|
|
CHECK(fmt::format("{:.2%Q}", 1.2345q_m) == "1.23");
|
|
|
|
|
CHECK(fmt::format("{:.3%Q}", 1.2345q_m) == "1.235");
|
|
|
|
|
CHECK(fmt::format("{:.4%Q}", 1.2345q_m) == "1.2345");
|
|
|
|
|
CHECK(fmt::format("{:.5%Q}", 1.2345q_m) == "1.23450");
|
|
|
|
|
CHECK(fmt::format("{:.10%Q}", 1.2345q_m) == "1.2345000000");
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST_CASE("precision specification for integral representation should throw", "[text][fmt][exception]")
|
|
|
|
|
{
|
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
|
|
|
|
SECTION("default format {} on a quantity")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
REQUIRE_THROWS_MATCHES(fmt::format("{:.1}", 1q_m), fmt::format_error, Message("precision not allowed for integral quantity representation"));
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
SECTION("full format {:%Q %q} on a quantity")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
REQUIRE_THROWS_MATCHES(fmt::format("{:.1%Q %q}", 1q_m), fmt::format_error, Message("precision not allowed for integral quantity representation"));
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
SECTION("value only format {:%Q} on a quantity")
|
2019-11-06 16:50:34 +00:00
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
REQUIRE_THROWS_MATCHES(fmt::format("{:.1%Q}", 1q_m), fmt::format_error, Message("precision not allowed for integral quantity representation"));
|
2019-11-06 16:50:34 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-16 17:04:41 +02:00
|
|
|
|
// Restate operator<< definitions in terms of std::format to make I/O manipulators apply to whole objects
|
2019-10-18 15:34:46 +02:00
|
|
|
|
// rather than their parts
|
|
|
|
|
|
|
|
|
|
|
2019-12-23 13:22:37 +01:00
|
|
|
|
TEST_CASE("quantity_cast", "[text][ostream]")
|
|
|
|
|
{
|
|
|
|
|
std::stringstream stream;
|
|
|
|
|
|
|
|
|
|
SECTION("int to double representation")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 121q_km / 2q_h;
|
2019-12-23 13:22:37 +01:00
|
|
|
|
|
|
|
|
|
SECTION("original")
|
|
|
|
|
{
|
|
|
|
|
stream << q;
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "60 km/h");
|
2019-12-23 13:22:37 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("int")
|
|
|
|
|
{
|
|
|
|
|
stream << quantity_cast<int>(q);
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "60 km/h");
|
2019-12-23 13:22:37 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("double")
|
|
|
|
|
{
|
|
|
|
|
stream << quantity_cast<double>(q);
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "60 km/h");
|
2019-12-23 13:22:37 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("double to int representation")
|
|
|
|
|
{
|
2020-02-17 15:56:06 +01:00
|
|
|
|
const auto q = 121.q_km / 2q_h;
|
2019-12-23 13:22:37 +01:00
|
|
|
|
|
|
|
|
|
SECTION("original")
|
|
|
|
|
{
|
|
|
|
|
stream << q;
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "60.5 km/h");
|
2019-12-23 13:22:37 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("int")
|
|
|
|
|
{
|
|
|
|
|
stream << quantity_cast<int>(q);
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "60 km/h");
|
2019-12-23 13:22:37 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SECTION("double")
|
|
|
|
|
{
|
|
|
|
|
stream << quantity_cast<double>(q);
|
2020-02-20 18:02:21 +00:00
|
|
|
|
CHECK(stream.str() == "60.5 km/h");
|
2019-12-23 13:22:37 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|