docs: "Framework Basics" chapters updated and cleaned up

CHANGELOG.md

@@ -4,7 +4,7 @@
 
 ### 2.2.0 <small>WIP</small> { id="2.2.0" }
 
-- feat: `fma`, `isfinite`, `isinf`, and `isnan` math function added by @NAThompson
+- feat: `fma`, `isfinite`, `isinf`, and `isnan` math function added by [@NAThompson](https://github.com/NAThompson)
 - feat: `quantity_point` support added for `quantity_cast` and `value_cast`
 - feat: `value_cast<Unit, Representation>` added
 - (!) refactor: `zero_Fahrenheit` renamed to `zeroth_degree_Fahrenheit`
@@ -15,6 +15,7 @@
 - docs: project blog and first posts added
 - docs: project documentation layout refactored
 - docs: "Interoperability with Other Libraries" chapter added
+- docs: "Framework Basics" chapters updated and cleaned up
 
 ### 2.1.0 <small>December 9, 2023</small> { id="2.1.0" }
 

docs/users_guide/framework_basics/character_of_a_quantity.md

@@ -18,8 +18,8 @@
 Such distinction is important because each quantity character represents different properties
 and allows different operations to be done on its quantities.
 
-For example, imagine a physical units library that allows the creation of a `speed` quantity from both
-`length / time` and `length * time`. It wouldn't be too safe to use such a product, right?
+For example, imagine a physical units library that allows the creation of a $speed$ quantity from both
+$length / time$ and $length * time$. It wouldn't be too safe to use such a product, right?
 
 Now we have to realize that both of the above operations (multiplication and division) are not even
 mathematically defined for linear algebra types such as vectors or tensors. On the other hand, two vectors
@@ -34,36 +34,36 @@ results from both cases. This simply can't work.
 While defining quantities ISO 80000 explicitly mentions when a specific quantity has a vector or tensor
 character. Here are some examples:
 
-| Quantity               |  Character   |                 Quantity Equation                 |
-|------------------------|:------------:|:-------------------------------------------------:|
-| `duration`             |    scalar    |                 _{base quantity}_                 |
-| `mass`                 |    scalar    |                 _{base quantity}_                 |
-| `length`               |    scalar    |                 _{base quantity}_                 |
-| `path_length`          |    scalar    |                 _{base quantity}_                 |
-| `radius`               |    scalar    |                 _{base quantity}_                 |
-| `position_vector`      |  **vector**  |                 _{base quantity}_                 |
-| `velocity`             |  **vector**  |           `position_vector / duration`            |
-| `acceleration`         |  **vector**  |               `velocity / duration`               |
-| `force`                |  **vector**  |               `mass * acceleration`               |
-| `power`                |    scalar    |                `force ⋅ velocity`                 |
-| `moment_of_force`      |  **vector**  |             `position_vector × force`             |
-| `torque`               |    scalar    |         `moment_of_force ⋅ {unit-vector}`         |
-| `surface_tension`      |    scalar    |                `|force| / length`                 |
-| `angular_displacement` |    scalar    |              `path_length / radius`               |
-| `angular_velocity`     |  **vector**  | `angular_displacement / duration * {unit-vector}` |
-| `momentum`             |  **vector**  |                 `mass * velocity`                 |
-| `angular_momentum`     |  **vector**  |           `position_vector × momentum`            |
-| `moment_of_inertia`    | **_tensor_** |       `angular_momentum ⊗ angular_velocity`       |
+| Quantity                 |  Character   |                    Quantity Equation                    |
+|--------------------------|:------------:|:-------------------------------------------------------:|
+| $duration$               |    scalar    |                    _{base quantity}_                    |
+| $mass$                   |    scalar    |                    _{base quantity}_                    |
+| $length$                 |    scalar    |                    _{base quantity}_                    |
+| $path\; length$          |    scalar    |                    _{base quantity}_                    |
+| $radius$                 |    scalar    |                    _{base quantity}_                    |
+| $position\; vector$      |  **vector**  |                    _{base quantity}_                    |
+| $velocity$               |  **vector**  |             $position\; vector / duration$              |
+| $acceleration$           |  **vector**  |                  $velocity / duration$                  |
+| $force$                  |  **vector**  |                  $mass * acceleration$                  |
+| $power$                  |    scalar    |                 $force \cdot velocity$                  |
+| $moment\; of\; force$    |  **vector**  |            $position\; vector \times force$             |
+| $torque$                 |    scalar    |      $moment\; of\; force \cdot \{unit\; vector\}$      |
+| $surface\; tension$      |    scalar    |             $\lvert force \rvert / length$              |
+| $angular\; displacement$ |    scalar    |                $path\; length / radius$                 |
+| $angular\; velocity$     |  **vector**  | $angular\; displacement / duration * \{unit\; vector\}$ |
+| $momentum$               |  **vector**  |                    $mass * velocity$                    |
+| $angular\; momentum$     |  **vector**  |           $position\; vector \times momentum$           |
+| $moment\; of\; inertia$  | **_tensor_** |     $angular\; momentum \otimes angular\; velocity$     |
 
 In the above equations:
 
-- `a * b` - regular multiplication where one of the arguments has to be scalar
-- `a / b` - regular division where the divisor has to be scalar
-- `a ⋅ b` - dot product of two vectors
-- `a × b` - cross product of two vectors
-- `|a|` - magnitude of a vector
-- `{unit-vector}` - a special vector with the magnitude of `1`
-- `a ⊗ b` - tensor product of two vectors or tensors
+- $a * b$ - regular multiplication where one of the arguments has to be scalar
+- $a / b$ - regular division where the divisor has to be scalar
+- $a \cdot b$ - dot product of two vectors
+- $a \times b$ - cross product of two vectors
+- $\lvert a \rvert$ - magnitude of a vector
+- $\{unit\; vector\}$ - a special vector with the magnitude of $1$
+- $a \otimes b$ - tensor product of two vectors or tensors
 
 !!! note
 

docs/users_guide/framework_basics/dimensionless_quantities.md

@@ -2,7 +2,7 @@
 
 The quantities we discussed so far always had some specific type and physical dimension.
 However, this is not always the case. While performing various computations, we sometimes end up with
-so-called "dimensionless" quantities, which ISO correctly defines as
+so-called "dimensionless" quantities, which ISO defines as
 [quantities of dimension one](../../appendix/glossary.md#dimensionless-quantity):
 
 !!! quote "ISO/IEC Guide 99"
@@ -70,8 +70,8 @@ static_assert(q.quantity_spec == isq::work / isq::heat);
 
 As shown above, the result is not of a `dimensionless` type anymore. Instead, we get a quantity type
 derived from the performed [quantity equation](../../appendix/glossary.md#quantity-equation).
-According to the [ISQ](../../appendix/glossary.md#isq), work divided by heat is the recipe for
-the thermodynamic efficiency quantity, thus:
+According to the [ISQ](../../appendix/glossary.md#isq), _work_ divided by _heat_ is the recipe for
+the _thermodynamic efficiency_ quantity, thus:
 
 ```cpp
 static_assert(implicitly_convertible(q.quantity_spec, isq::efficiency_thermodynamics));
@@ -91,7 +91,7 @@ Now, let's see what happens when we divide two quantities of the same type but d
 constexpr QuantityOf<dimensionless> auto q = isq::height(4 * km) / isq::height(2 * m);
 ```
 
-This time we still get a quantity of `dimensionless` type with a `dimension_one` as its dimension.
+This time, we still get a quantity of the `dimensionless` type with a `dimension_one` as its dimension.
 However, the resulting unit is not `one` anymore:
 
 ```cpp
@@ -101,16 +101,16 @@ static_assert(q.unit == mag_power<10, 3> * one);
 In case we would print the text output of this quantity, we would not see a raw value of `2000`,
 but `2 km/m`.
 
-First, it may look surprising, but this is actually consistent with the division of quantities
+First, it may look surprising, but this is consistent with dividing quantities
 of different dimensions. For example, if we divide `4 * km / 2 * s`, we do not expect `km` to be
 "expanded" to `m` before the division, right? We would expect the result of `2 km/s`, which is
 exactly what we get when we divide quantities of the same kind.
 
 This is a compelling feature that allows us to express huge or tiny ratios without the need
 for big and expensive representation types. With this, we can easily define things like
-a [Hubble's constant](https://en.wikipedia.org/wiki/Hubble%27s_law#Dimensionless_Hubble_constant)
+a [_Hubble's constant_](https://en.wikipedia.org/wiki/Hubble%27s_law#Dimensionless_Hubble_constant)
 that uses a unit that is proportional to the ratio of kilometers per megaparsecs, which are both
-units of length:
+units of _length_:
 
 ```cpp
 inline constexpr struct hubble_constant :
@@ -123,12 +123,12 @@ inline constexpr struct hubble_constant :
 Another important use case for dimensionless quantities is to provide strong types for counts
 of things. For example:
 
-- ISO-80000-3 provides a `rotation` quantity defined as the number of revolutions,
-- IEC-80000-6 provides a `number_of_turns_in_a_winding` quantity,
-- IEC-80000-13 provides a `Hamming_distance` quantity defined as the number of digit positions
+- ISO-80000-3 provides a _rotation_ quantity defined as the number of revolutions,
+- IEC-80000-6 provides a _number of turns in a winding_ quantity,
+- IEC-80000-13 provides a _Hamming distance_ quantity defined as the number of digit positions
   in which the corresponding digits of two words of the same length are different.
 
-Thanks to assigning strong names to such quantities, later on they can be explicitly used as
+Thanks to assigning strong names to such quantities, later on, they can be explicitly used as
 arguments in the [quantity equations](../../appendix/glossary.md#quantity-equation) of other
 quantities deriving from them.
 
@@ -165,17 +165,17 @@ inline constexpr struct per_mille : named_unit<basic_symbol_text{"‰", "%o"}, m
 
 ## Angular quantities
 
-Special, often controversial, examples of dimensionless quantities are an angular measure
-and solid angular measure quantities that are defined in the [ISQ](../../appendix/glossary.md#isq)
-to be the result of a division of `arc_length / radius` and `area / pow<2>(radius)` respectively.
+Special, often controversial, examples of dimensionless quantities are an _angular measure_
+and _solid angular measure_ quantities that are defined in the [ISQ](../../appendix/glossary.md#isq)
+to be the result of a division of $arc\; length / radius$ and $area / radius^2$ respectively.
 Moreover, [ISQ](../../appendix/glossary.md#isq) also explicitly states that both can be
-expressed in the unit `one`. This means that both `isq::angular_measure` and `isq::solid_angular_measure`
-should be of a [kind](../../appendix/glossary.md#kind) of `dimensionless`.
+expressed in the unit `one`. This means that both _angular measure_ and _solid angular measure_
+should be of a [kind](../../appendix/glossary.md#kind) dimensionless.
 
-On the other hand, [ISQ](../../appendix/glossary.md#isq) also specifies that a unit `radian` can
-be used for `isq::angular_measure`, and a unit `steradian` can be used for `isq::solid_angular_measure`.
+On the other hand, [ISQ](../../appendix/glossary.md#isq) also specifies that a unit radian can
+be used for _angular measure_, and a unit steradian can be used for _solid angular measure_.
 Those should not be mixed or used to express other types of dimensionless quantities. This means
-that both `isq::angular_measure` and `isq::solid_angular_measure` should also be
+that both _angular measure_ and _solid angular measure_ should also be
 [quantity kinds](../../appendix/glossary.md#kind) by themselves.
 
 !!! note
@@ -187,8 +187,8 @@ that both `isq::angular_measure` and `isq::solid_angular_measure` should also be
 
 ## Nested quantity kinds
 
-Angular quantities are not the only ones with such a "strange" behavior. Another, but a similar case
-is a `storage_capacity` quantity specified in IEC-80000-13 that again allows expressing it in both
+Angular quantities are not the only ones with such a "strange" behavior. Another but a similar case
+is a _storage capacity_ quantity specified in IEC-80000-13 that again allows expressing it in both
 `one` and `bit` units.
 
 Those cases make dimensionless quantities an exceptional tree in the library. This is the only
@@ -245,4 +245,4 @@ inline constexpr struct steradian : named_unit<"sr", square(metre) / square(metr
 inline constexpr struct bit : named_unit<"bit", one, kind_of<storage_capacity>> {} bit;
 ```
 
-but still allow a usage of `one` and its scaled versions for such quantities.
+but still allow the usage of `one` and its scaled versions for such quantities.

docs/users_guide/framework_basics/faster_than_lightspeed_constants.md

@@ -1,8 +1,8 @@
 # Faster-than-lightspeed Constants
 
 In most libraries, physical constants are implemented as constant (possibly `constexpr`)
-quantity values. Such an approach has some disadvantages, often resulting in longer
-compilation times and a loss of precision.
+quantity values. Such an approach has some disadvantages, often affecting the run time
+performance and causing a loss of precision.
 
 
 ## Simplifying constants in an equation
@@ -16,7 +16,7 @@ performance and often a better precision of the resulting value.
 
 ## Physical constants as units
 
-The **mp-units** library allows and encourages implementing physical constants as
+The **mp-units** library allows and encourages the implementation of physical constants as
 regular units. With that, the constant's value is handled at compile-time, and under
 favorable circumstances, it can be simplified in the same way as all other repeated
 units do. If it is not simplified, the value is stored in a type, and the expensive
@@ -53,7 +53,7 @@ inline constexpr struct magnetic_constant :
 
 ## Usage examples
 
-With the above definitions, we can calculate vacuum permittivity as:
+With the above definitions, we can calculate _vacuum permittivity_ as:
 
 ```cpp
 constexpr auto permeability_of_vacuum = 1. * si::magnetic_constant;
@@ -72,9 +72,9 @@ permittivity of vacuum = 1  μ₀⁻¹ c⁻² = 8.85419e-12 F/m
 
 As we can clearly see, all the calculations above were just about multiplying and dividing
 the number `1` with the rest of the information provided as a compile-time type. Only when
-a user wants a specific SI unit as a result the unit ratios are lazily resolved.
+a user wants a specific SI unit as a result, the unit ratios are lazily resolved.
 
-Another similar example can be an equation for total energy:
+Another similar example can be an equation for _total energy_:
 
 ```cpp
 QuantityOf<isq::mechanical_energy> auto total_energy(QuantityOf<isq::momentum> auto p,