numeric_field read the field off a scalar element, so a container storing a
complex element (e.g. a wrapper over std::complex<double>) was classified complex
even when it did not expose real()/imag() on its own surface. Such a type cannot
actually be used as a complex representation, yet it satisfied the complex slot.
A vector or tensor is now complex only when its element is complex AND the
container itself exposes the real()/imag() decomposition API. When the element is
complex but that API is missing, numeric_field is left unspecified rather than
guessed (which would pick a Euclidean instead of a Hermitian magnitude), exactly
as tensor_order is left unspecified for an ambiguous shape: the type is then not a
representation until the author exposes the API or specializes numeric_field.
A real container that merely exposes element-wise real()/imag() (as real Eigen and
Blaze matrices do) stays real, because the field is read off the real element.
The consistency check uses a consteval helper with if constexpr so the element
aliases and the recursive detect_numeric_field call are only instantiated for the
matching order.
Verified on the supported matrix: gcc 12/15/16 and clang 16/21. (clang-22 is
unreleased and fails to build mp-units on master independently of this change.)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Eigen/GLM/Blaze integration story was spread across the User's Guide
reference, a subsection of the custom-representation how-to, and the linear
algebra example, and the Integration chapter never named it. Meanwhile
"Interoperability with Other Libraries" was actually about quantity_like_traits
and std::chrono, not linear algebra.
- Add "Using a Linear Algebra Library" how-to: the single home for the shipped
plugin table (header/module/CMake target), the CMake linking recipe for both
header and module mode, the recipe for adapting a library with no plugin, and
the expression-template/Armadillo/V2 caveats.
- Rename "Interoperability with Other Libraries" to "Converting to and from
External Quantity Types" to match its actual content; update all inbound links.
- Trim the duplicated vector-library-adaptation block from the custom-rep guide
and point it at the new guide.
- Shrink the User's Guide "Third-Party Library Integrations" section to a pointer
so the new guide is the single source of truth.
- Clarify in Project Structure that an integration target links only core + the
third-party library, so it must be linked alongside mp-units::mp-units.
- Cross-link the units-meet-linear-algebra blog post to the new guide.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The mp_units::utility representation types shipped from flat header paths
(mp-units/cartesian_vector.h, cartesian_tensor.h, random.h) while the
core-side utility headers (safe_int, constrained, representation) already
live under mp-units/utility/. Unify the layout so the include path mirrors
the mp_units::utility namespace:
- move cartesian_vector.h, cartesian_tensor.h, random.h into mp-units/utility/;
- keep deprecated forwarding headers at the old paths for the released
cartesian_vector and random (a #warning plus an include of the new path);
- cartesian_tensor is new in 2.6.0, so it ships only at the new path;
- repoint all in-tree consumers (tests, example, docs) to the new paths so
they do not trip the deprecation #warning under -Werror;
- update the Project Structure guide and the prose reference in
quantity_arithmetics.
Verified full runtime + static suites on gcc-12/gcc-15 (headers) and
clang-16 (headers) / clang-21 (modules): 129906 assertions each.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
numeric_field reads the field off a scalar element (no field adapter for Eigen/Blaze) and follows
tensor_order's availability; tensor_order is undefined for an ambiguous type and must be specialized.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a Namespaces section to the project structure docs describing the three
public tiers (mp_units / mp_units::utility / mp_units::detail), show the
core -> systems -> utility module layering, and list the utility headers.
Update the representation and custom-representation guides to introduce the
built-in cartesian types via mp_units::utility, and update the safe_int /
constrained material (guide, blog posts, tutorials) to the new
<mp-units/utility/...> include paths and mp_units::utility names.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Describe `cartesian_vector<T, N>` / `cartesian_tensor<T, N>` as N-dimensional /
NxN with a compile-time dimension N (2 or 3, default 3), and show dimension
deduction plus embed/project converting between the plane and space.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rework the "Character of a Quantity" chapter for the order x field model and record the change
in the changelog.
- character_of_a_quantity.md: two-axis framing up front; a new "Real and complex quantities"
section; the `quantity_tensor_order`/`quantity_field` enum and `quantity_character` struct
definitions shown before use; an expanded ordering example (explicit vector, inherited
vector, explicit tensor) and a complex declaration; the ISO 80000-2 rank-ordering quote; and
the experimental warning removed. Deprecated `quantity_character::vector` examples updated to
the two-axis spelling.
- CHANGELOG.md: 2.6.0 entries for the two-axis split, `cartesian_tensor`, the
`numeric_field`/`tensor_order` customization points, the flat-enum deprecation and
customization rework, and the magnitude/decomposition fixes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`quantity::magnitude()` was constrained to an exact `quantity_character{vector}` (i.e.
`{vector, real}`), which silently excluded tensor quantities and complex vectors even though
both have a well-defined norm. It now requires `order >= vector` (vectors and tensors, any
field) plus `HasMagnitude<rep>` so the storage can actually produce one - the latter cleanly
withholds the member instead of letting the body hard-error when the rep has no magnitude.
The `magnitude` CPO gained the missing complex-scalar branch: a complex scalar is a degenerate
1D complex vector, so its magnitude is the modulus `|z|`, symmetric with the real-scalar
`std::abs` branch (a `double` standing in as a 1D real vector).
Vector decomposition (`vector_components` primary template and `ValidVectorAxes`) dropped the
real-field pin, keying on `order == vector` alone, so complex vector quantities decompose into
their complex 1D components. The order pin stays (a tensor is not a flat vector decomposition).
Adds static tests (magnitude over scalar/vector/tensor and real/complex/degenerate reps;
complex-field decomposition) asserting the intended design, and documents the complex-scalar
magnitude path in the representation-types guide.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Consolidate the representation opt-outs into one character-agnostic customization
point and align the documentation with the two-axis model.
- Add `disable_representation<T>` in `customization_points.h`: a specializable
opt-out that bars a type from being a quantity representation regardless of
character. Its default (`is_quantity_abstraction<value_type_t<T>>`) rejects a
quantity or quantity-like type, and any container of them; `bool` is opted out
explicitly. This retires both `disable_real` and the `NotQuantity` guard.
- Rename the internal predicate `is_quantity_like` -> `is_quantity_abstraction`
(it covers `Quantity || QuantityLike`) so it no longer collides with the
`QuantityLike` customization family.
- The representation tier now leads with one shared `RepresentationBaseline`
guard (not opted out + `UnitMagnitudeScalable`), which short-circuits a quantity
before any character concept instantiates its operators (avoiding a
satisfaction cycle).
- Docs: restructure `representation_types.md` around the two character axes
(field via `numeric_field`, order via `tensor_order`) with a common baseline,
the new `disable_representation` section, and consistent unit-magnitude-aware
scaling terminology; align `concepts.md` and `using_custom_representation_types.md`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rewrap a 91-column line in the `disable_tensor` paragraph to satisfy markdownlint MD013.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mateusz Pusz