mpusz/mp-units
1
0
Fork 1
mirror of https://github.com/mpusz/mp-units.git synced 2025-07-31 19:04:27 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: grammar and spelling of ISQ Part 5 improved

Browse Source
This commit is contained in:
Mateusz Pusz
2024-11-04 11:58:01 +01:00
parent 614ecb5c42
commit d249bc1400
1 changed files with 25 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
docs/blog/posts/isq-part-5-benefits.md
View File

@@ -9,12 +9,12 @@ comments: true
# International System of Quantities (ISQ): Part 5 - Benefits # International System of Quantities (ISQ): Part 5 - Benefits
In the previous articles we have introduced the International System of Quantities, described how In the previous articles, we introduced the International System of Quantities, described how we
we can model and implement it in a programming language, and presented the issues of the software can model and implement it in a programming language, and presented the issues of software that
that does not use such abstraction to implement a units library. does not use such abstraction to implement a units library.
Some of the issues raised in [Part 2](isq-part-2-problems-when-isq-is-not-used.md) of our series Some of the issues raised in [Part 2](isq-part-2-problems-when-isq-is-not-used.md) of our series
were addressed in [Part 3](isq-part-3-modeling-isq.md) already. In this article we will present were addressed in [Part 3](isq-part-3-modeling-isq.md) already. This article will present
how our ISQ model elegantly addresses the remaining problems. how our ISQ model elegantly addresses the remaining problems.
<!-- more --> <!-- more -->
@@ -35,7 +35,7 @@ Let's start with the implementation of a
The resulting quantity should use a derived unit of the provided arguments (e.g., `km/h` for The resulting quantity should use a derived unit of the provided arguments (e.g., `km/h` for
`km` and `h`, `m/s` for `m` and `s`, ...). `km` and `h`, `m/s` for `m` and `s`, ...).
With C++ concepts backed up with ISQ quantities we can simply type it as: With C++ concepts backed up with ISQ quantities, we can simply type it as:
```cpp ```cpp
constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,
@@ -46,9 +46,9 @@ constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,
``` ```
The above constrains the algorithm to proper quantity types and ensures that a quantity of speed The above constrains the algorithm to proper quantity types and ensures that a quantity of speed
is returned. The latter is not only important for the users to better understand what the function is returned. The latter is essential not only for the users to better understand what the function
does, but also serves as a unit test for our implementation. It ensures that our quantity equations does but also serves as a unit test for our implementation. It ensures that our quantity equations
are correct in the implementation part of the function and we indeed return a quantity of _speed_. are correct in the implementation part of the function, and we indeed return a quantity of _speed_.
## Non-convertible units of currency ## Non-convertible units of currency
@@ -80,7 +80,7 @@ inline constexpr auto USD = us_dollar;
static_assert(!std::equality_comparable_with<quantity<euro, int>, quantity<us_dollar, int>>); static_assert(!std::equality_comparable_with<quantity<euro, int>, quantity<us_dollar, int>>);
``` ```
Next, we can provide custom currency exchange facility that accounts for a specific point in time: Next, we can provide a custom currency exchange facility that accounts for a specific point in time:
```cpp ```cpp
template<Unit auto From, Unit auto To> template<Unit auto From, Unit auto To>
@@ -115,16 +115,16 @@ std::cout << price_usd << " -> " << price_euro << "\n";
!!! note !!! note
It would be better to model the above prices as quantity points, but this is a subject It would be better to model the above prices as quantity points, but this is a subject
for a totally different article :wink:. for a different article :wink:.
## Derived quantities of the same dimension but different kinds ## Derived quantities of the same dimension but different kinds
Up until now, the discussed issues did not actually require modeling of the ISQ. Introduction Until now, the issues discussed have not actually required modeling of the ISQ. The introduction
of physical dimensions would be enough, and indeed, this is what most of the libraries on the of physical dimensions would be enough, and indeed, this is what most of the libraries on the
market do. However, we have more interesting challenges to solve as well. market do. However, we have more exciting challenges to solve as well.
The next issue was related to different quantities having the same dimension. In many cases we The next issue was related to different quantities having the same dimension. In many cases, we
want to prevent conversions and any other compatibility between such distinct quantities. want to prevent conversions and any other compatibility between such distinct quantities.
Let's try to implement Let's try to implement
@@ -154,14 +154,14 @@ static_assert(!castable(q2.quantity_spec, isq::area));
``` ```
As we can see, with just units (especially derived ones) and dimensions, we often can't achieve As we can see, with just units (especially derived ones) and dimensions, we often can't achieve
the same level of safety as with properly modelled hierarchies of quantities. Only in case of `q2` the same level of safety as with adequately modeled hierarchies of quantities. Only in case of `q2`
we can prevent incorrect conversions to a totally different quantity of the same dimension. we can prevent incorrect conversions to a different quantity of the same dimension.
## Various quantities of the same dimension and kinds ## Various quantities of the same dimension and kinds
In the previous example _area_ and _fuel consumption_ were quantities of the same dimension but In the previous example, _area_ and _fuel consumption_ were quantities of the same dimension but
different kinds. In the engineering there are also many cases where we need to model distinct of different kinds. In engineering, there are also many cases where we need to model distinct
quantities of the same kind. quantities of the same kind.
Let's try to improve the safety of Let's try to improve the safety of
@@ -193,12 +193,11 @@ static_assert(implicitly_convertible(horizontal_length * isq::width, isq::area))
static_assert(implicitly_convertible(horizontal_length * isq::width, horizontal_area)); static_assert(implicitly_convertible(horizontal_length * isq::width, horizontal_area));
``` ```
With simple 2 lines of definitions we made all of the above logic automatically work without With simple two lines of definition, we made the above logic automatically work without needing
any need for additional customization for special cases. The proposed model based on additional customization for special cases. Based on hierarchies of derived quantities and their
hierarchies of derived quantities and their recipes, automatically inherits the properties recipes, the proposed model automatically inherits the properties of base quantities involved in
of base quantities involved in the recipe. This makes the composition of derived quantities the recipe. This makes the composition of derived quantities very easy, which is not true for
very easy which is not the case for alternative solutions based on tag types that do not alternative solutions based on tag types that do not compose their properties.
compose their properties.
Now we can refactor our `Box` to benefit from the introduced safe abstractions: Now we can refactor our `Box` to benefit from the introduced safe abstractions:
@@ -249,9 +248,9 @@ dedicated unit (e.g., `bit`, `rad`, `sr`), should also be able to be measured in
We've seen how to model such a hierarchy in a We've seen how to model such a hierarchy in a
[previous article in our series](isq-part-4-implemeting-isq.md#modeling-a-hierarchy-of-kind-dimensionless). [previous article in our series](isq-part-4-implemeting-isq.md#modeling-a-hierarchy-of-kind-dimensionless).
This time, we will see a simplified part of a concrete real-life example for this use cases. This time, we will see a simplified part of a concrete, real-life example for this use case.
In the digital signal processing domain we need to provide strong types for different counts. We often need to provide strong types for different counts in the digital signal processing domain.
Abstractions like _samples_, _beats_, _MIDI clock_, and others should not be possible to be Abstractions like _samples_, _beats_, _MIDI clock_, and others should not be possible to be
intermixed with each other: intermixed with each other:
@@ -324,7 +323,7 @@ inline constexpr auto n_16th = SixteenthNote;
} // namespace ni } // namespace ni
``` ```
With the above we can work with each quantity in a safe way and use SI or domain-specific units With the above, we can safely work with each quantity and use SI or domain-specific units
as needed: as needed:
```cpp ```cpp