Commit Graph
92 Commits
Author SHA1 Message Date
Mike Ford 8230a42cb0 added some units for the foot-pound-second system and the static tests 2020-06-16 15:14:46 +02:00
Mateusz Pusz 86b9177816 Specialize common_type to satisfy comparison concepts (resolves #113) 2020-05-28 20:19:05 +02:00
Mateusz Pusz 61fadb8ebc dim_velocity renamed to dim_speed 2020-05-14 16:00:38 +02:00
Mateusz Pusz ce301748dd Velocity renamed to Speed (resolves #103) 2020-05-10 17:31:47 +02:00
Mateusz Pusz 7e935a4108 Physical units put in the physical namespace (I am sorry) 2020-05-08 22:39:24 +02:00
Mateusz Pusz 1830735544 Unit tests for alias_unit added 2020-05-08 21:18:16 +02:00
Ramzi Sabra 7b8ad8e37c changed hectare to an alias_unit 2020-05-08 10:41:38 +02:00
Ramzi Sabra 6f8bddc832 added more prefixed SI units; added alias_unit and prefixed_alias_unit types 2020-05-08 10:41:38 +02:00
Mateusz Pusz 202a2b0823 Missing dimension concepts tests added 2020-05-07 09:25:34 +02:00
Mateusz Pusz ff21e1e899 GCC 10 compilation fixed 2020-05-05 21:25:56 +02:00
rbrugo 9ec5c77602 Added molar heat capacity 2020-04-10 16:36:08 +02:00
rbrugo 7dda8319a2 Added molar energy 2020-04-10 16:36:08 +02:00
rbrugo 89dbc30a92 Added permeability 2020-04-10 16:36:08 +02:00
rbrugo 596161cca5 Added permittivity 2020-04-10 16:36:08 +02:00
rbrugo 1cf0074483 Added charge density 2020-04-10 16:36:08 +02:00
rbrugo 7803da0bdf Added electric field strength 2020-04-10 16:36:08 +02:00
rbrugo 15138286e5 Added thermal conductivity 2020-04-10 16:36:08 +02:00
rbrugo 017e88ca28 Added heat capacity and specific heat capacity 2020-04-10 16:36:08 +02:00
rbrugo 07b5364c97 Added dynamic viscosity 2020-04-10 16:36:08 +02:00
rbrugo 4b4cc70764 Added luminance 2020-04-10 16:36:08 +02:00
rbrugo 8ddd7e1233 Added concentration 2020-04-10 16:36:08 +02:00
rbrugo e6b34b6b1b Added current density 2020-04-10 16:36:08 +02:00
rbrugo 43f475fb80 Added absorbed dose 2020-04-10 16:36:08 +02:00
rbrugo 561773da7e Added catalytic activity 2020-04-10 16:36:08 +02:00
rbrugo 3cd77de2e9 Added conductance 2020-04-10 16:36:08 +02:00
rbrugo 14f00ef775 Added inductance 2020-04-10 16:36:08 +02:00
rbrugo 86eefe1b0d Added magnetic flux 2020-04-10 16:36:08 +02:00
rbrugo 7b0ba64cba Static tests for magnetic induction 2020-04-10 16:36:08 +02:00
Mateusz Pusz f5df68253e symbol_text refactored 2020-03-27 15:21:05 +01:00
Mateusz Pusz 2a77e20cc6 Unit test renamed 2020-03-27 10:08:19 +01:00
Ramzi Sabra b8073b79d0 replaced ASCII part comparison with assert ensuring same comparison result as for standard part 2020-03-27 10:03:59 +01:00
Ramzi Sabra 60d9a9036a added more operators; added tests 2020-03-27 10:03:59 +01:00
Mateusz Pusz f2c14dfa34 Lack of CTAD for aliases fixed for gcc-9 2020-03-25 15:59:45 +01:00
Mateusz Pusz ab1cc4b8e7 Overconstrained quantity operations relaxed 2020-03-25 15:04:33 +01:00
Mateusz Pusz 0a906450a2 Custom representation tests moved to a new file 2020-03-24 22:56:11 +01:00
Mateusz Pusz 6a5f25750d UDL naming refactored 2020-03-10 20:53:53 +01:00
Mateusz Pusz c745bebffd type_list_join added 2020-02-24 15:15:46 +01:00
Mateusz Pusz 0c89df3980 unknown_unit renamed to unknown_coherent_unit 2020-02-22 09:37:40 +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 18620044c5 All UDLs are now prefixed with q_ 2020-02-17 15:56:06 +01:00
Oliver Schönrock 0566cc631d implementing units::ratio_add and tests
not yet used in src/include/units/bits/dim_consolidate.h
because it breaks and cascades (due to new exponent we think)
2020-02-16 14:53:06 +01:00
Oliver Schönrock 291d3d1eb7 dealing with exponent during sqrt
fixes #58
2020-02-16 14:53:06 +01:00
Mateusz Pusz a8ada63031 units::exp disambiguated in unit tests 2020-02-12 09:49:49 +01:00
Mateusz Pusz 2360392a3d Tests for #58 added (uncomment when fixed) 2020-02-11 08:51:34 +01:00
Mateusz Pusz 037503cbc6 deduced_unit fixed + unit test for mass unit added 2020-02-10 20:35:32 +01:00
Andy Little 024f5a9c83 change const order
move in,ft,fathom,ft2,ft3,mph from us to international namespace
TODO distinguish units with different names for same values
2020-01-12 21:34:36 +01:00
Andy Little 283e9d81a3 Split the various non-si length units into their own namespaces.
new namespaces are
international ( combination of us and imperial + Canada etc)
iau  (https://www.iau.org/
imperial ( old imperial units)
typographical ( for sizes of printing fonts etc)

These namespace are based on some research , mainly on wikipedia.
Look in src/include/units/physical/si/length.h to see links to see the references to documentation justifying the change.

Unfortunately there are 3 foot units for example, an old imperial version, an old us version and an international version, which is more recent and attempts to unify the two previous ones. All versions have slight changes in value, so I opted to use the international version
The main change in the layout is that inch,foot and yard have been moved from us to international.

With this modification, I also modified the physical/us/area.hpp, volume.hpp and volume.hpp headers to refer to the international units.
This may not be correct, but if the modified us::foot (rather than international foot is used as a basis for these units, then
there is a ratio integer overflow during compilation, probably due to taking 3rd power of a ratio. After this commit. I will try to show that on another branch.
2020-01-12 21:34:36 +01:00
Mateusz Pusz a01c811f5f Square and cubic UDLs renamed 2020-01-09 10:03:41 +01:00
Oliver Schönrock 509b6c9653 implementing ratio<num,den,exp> which replaces ratio<num,den>
https://github.com/mpusz/units/issues/14

This "works", as in it passes all static and runtime tests.
However quite a few of the tests have been "modified" to make them pass. Whether
this is legitimate is debatable and should be the source of some thought /
discussion.

1. many of the static tests and some of the runtime tests have had the input
ratios of the tests modified in the following way. eg ratio<3,1000> =>
ratio<3,1,-3>. ie they have been "canonicalised".

There are obviously an infinite number of ratios which represent the same
rational number. The way `ratio` is implemented it always moves as "many powers
of 10" from the `num` and `den` into the `exp` and that makes the `canonical`
ratio.

Because these are all "types" and the lib uses is_same all over the place, only
exact matches will be `is_same`. ie ratio<300,4,0> !is_same ratio<3,4,2> (the
latter is the canonical ratio). This is perhaps fine for tests in the devlopment
phase, but there may be a need for "more forgiving" comparison / concept of
value equality. One such comparison which compares den,num,exp after
canonicalisation is the constexpr function `same` as defined at top of
`ratio_test.cpp`. We may need to expose this and perhaps add even more soft
comparisions.

2. In the runtime tests it is "subjective" how some resukts should be
printed. There is the question of "how exactly to format certain ratios". eg
omit denominators of "1" and exponents of "0". However before even addressing
these in detail a decision needs to be made about the general form of
"non-floating-point-converted" ratios which do not map exactly to a "Symbol
prefix".

Arguably these are "relatively ugly" whatever we do, so we could just
go for an easily canonicalised form. An example is:

-        CHECK(stream.str() == "10 [1/60]W");
+        CHECK(stream.str() == "10 [1/6 x 10⁻¹]W");

Which of thses is "better"? Is there a "third", better form?  It's not obvious.

My opnion is: Both of 1&2 are fine for now, unless we think they go down the
wrong avenue, and can be "perfected later"? ie we can expose a softer version of
ratio based equality, and decide on canonical way of printing ratios (as far as
that is actually a very useful output form, compared with decimal, scientific or
engineering notation).
2019-12-28 17:59:47 +01:00
Mateusz Pusz 594f92241a tonne added 2019-12-26 10:27:20 +01:00