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>
Broaden the "a vector quantity supports magnitude()" note to "vector or tensor quantity" and
name the norm variants (Euclidean for a real vector, Frobenius for a tensor, Hermitian for a
complex one), matching the shipped magnitude() character constraint.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the "a vector is a tensor of the first order and a scalar is a tensor of order zero"
quote to the underdetermined-type section, where the article shows one double serving scalar,
vector, and tensor quantities, and add a matrix-vs-tensor paragraph to "The type lies": a
matrix is storage, a tensor is defined by its transformation law, so whether a Matrix3d is a
tensor is a fact about the quantity, not the type.
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>
Iterate the in-progress essay (still draft). Restructure the motivation as a three-tab
strong-quantities comparison (plain double, loose auto parameters, proper constraints) built
on a speedometer `closing_speed` example, and split character's two jobs into a bulleted list.
Correct several technical claims surfaced in review:
- mass/weight differ by dimension, not character (matching the article's own opening);
- a real representation cannot grow an imaginary part - there is no silent complex-to-real
drop, since `std::complex` does not convert to `double`;
- the "scalar-as-vector workaround" was the `is_vector` opt-in the Kalman example carried, not
the later `disable_vector` opt-out;
- `magnitude()` is defined on vectors and tensors, real and complex, and ships today for the
scalar-rejection case.
Add concrete complex vector/tensor quantities (phasor field, permittivity tensor), the
degenerate stress-tensor case in the underdetermined-type example, and an admonition for the
thesis.
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>
Update the systems reference generator for the two-axis quantity character and to reduce
the quantities table width:
- The Character column now prints the order with a `complex` prefix only when the field is
complex (`scalar`, `complex scalar`, `vector`, `tensor`, `complex vector`,
`complex tensor`), replacing the old `Real`/`Complex`/`Vector`/`Tensor` labels that mixed
the two axes and could not express complex vectors or tensors.
- The separate `is_kind` and `non_negative` boolean columns are merged into one `Traits`
column that shows `kind` and/or `≥ 0` only when set (blank otherwise), dropping a column
and the per-row ticks.
Regenerated the affected systems reference pages.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The QUANTITY_SPEC parser only recognized `quantity_character::` as a character override,
and the generated metadata-extraction program `switch`ed over the character enum. Both
broke once the ISQ definitions moved to the `quantity_tensor_order` / `quantity_field`
spelling and `quantity_character` became a struct.
- Treat `quantity_tensor_order::` and `quantity_field::` (alongside `quantity_character::`)
as character overrides when deciding whether the third macro argument is an equation.
- Rewrite `character_to_string` to compare against the two-axis values instead of switching
on an enum.
The regenerated reference is byte-identical (only the source hash changes).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The previous `195+` is the Conan-side encoding (matching
`_feature_compatibility` in conanfile.py) and is ambiguous in prose —
the digits collide with `_MSC_VER`/cl-version/toolset variants. The
cl-version `19.5+` is what users see from `cl /version`, and what's
already used in src/CMakeLists.txt when this project talks about MSVC
versions. Realign the MSVC column to accommodate the wider cell.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mp-units' minimum-supported MSVC 195 (VS 2026) has solid `import std;`
support, but enabling `-o import_std=True` against the build hit two
issues that this change fixes.
(1) Module scanning was only enabled when `cxx_modules=True`.
Without `CMAKE_CXX_SCAN_FOR_MODULES=ON`, CMake doesn't link the implicit
std module BMI into non-module translation units that do `import std;`,
producing C2230 "could not find module 'std'". Enable scanning whenever
`import_std=True` as well. Same bug fixed in `test_package/conanfile.py`.
(2) The std module BMI is built with mismatched compile flags.
CMake materializes the implicit std module BMI as `__cmake_cxx_std_NN`,
a separate internal target that does not link mp-units and therefore
does not inherit mp-units' target-level options. On MSVC this caused
C5050 (`_UTF8` defined on consumer but not on module command line) and
on Clang 21 there is a parallel `-Wreserved-module-identifier` issue
already partially handled in `src/CMakeLists.txt` but in a directory
scope that did not actually reach the BMI either.
Consolidate the workarounds into one `src/cmake/import-std-setup.cmake`
snippet that applies the flags project-wide via `add_compile_options`,
self-guarded by `if(NOT CMAKE_CXX_MODULE_STD) return()`. It is included
from every entry point so all delivery paths converge:
- top-level `CMakeLists.txt` for the dev build
- bundled `mp-unitsConfig.cmake` for `find_package` consumers
- via `cmake_build_modules` in `package_info()` for Conan-generated
configs (the `cxx_modules=False` consumer path)
Other pieces:
- `test/static/unit_magnitude_test.cpp` was the only test in the repo
missing the `MP_UNITS_IMPORT_STD` gate around `#include <type_traits>`,
causing duplicate `std::integral_constant` definitions in this
configuration.
- Compiler support table announces MSVC 195+ for `import std;`.
- Installation docs gain a consumer-side setup note covering the
CMake cache variables required, what mp-units handles automatically
via the snippet, and the `add_subdirectory`-vendored caveat.
Verified: `conan build . -pr msvc195 -o '&:cxx_modules=False'
-o '&:import_std=True' -s compiler.cppstd=23 -c
user.mp-units.build:all=True` -> 40/40 tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>