Is your feature request related to a problem? Please describe.
UnitsNet currently appears to mix two different design models:
- algebraic quantity modeling
- context-driven curation of which quantity types and operators are allowed
That creates two related problems:
- some quantity types appear to duplicate the same algebraic quantity while differing only by usage context
- some accepted relations are not closed under inferred division because the reverse operators were judged “not intuitive”
A concrete example of the first is Density and MassConcentration.
They are both defined as mass per unit volume:
- Density: total mass per unit volume of the material or mixture
- MassConcentration: mass of a constituent per unit volume of the mixture
They have:
- the same base unit:
KilogramPerCubicMeter
- the same base dimensions:
M = 1, L = -3
So algebraically they are the same quantity, with the distinction belonging to usage context rather than the unit system itself.
A concrete example of the second is the use of -- NoInferredDivision, for example:
"Area.SquareMeter = KinematicViscosity.SquareMeterPerSecond * Duration.Second -- NoInferredDivision"
"Ratio.DecimalFraction = Area.SquareMeter * ReciprocalArea.InverseSquareMeter -- NoInferredDivision"
"Ratio.DecimalFraction = TemperatureDelta.Kelvin * CoefficientOfThermalExpansion.PerKelvin -- NoInferredDivision"
These relations are accepted in the forward direction, but their algebraically valid inverses are suppressed because the inferred reverse operators were considered unintuitive or ugly.
That makes the framework harder to reason about, because valid consequences of accepted relations are not always available.
Describe the solution you'd like
I’d like UnitsNet to prefer algebraic closure over assuming usage context.
More specifically:
-
Quantity identity should be determined algebraically first.
If two quantities have the same defining ratio form, dimensions, and unit algebra, they should not exist as separate root quantity types purely because they are used in different domains.
-
Accepted relations should be closed under their valid inverses by default.
If a multiplication relation is valid enough to exist, its inferred division operators should not be suppressed simply because the reverse expression seems unintuitive.
-
If domain-specific naming is important, that should be modeled explicitly as aliasing or semantic specialization, not by duplicating the algebraic root quantity or selectively removing valid operators.
In short: usage context should belong to the caller’s domain model, not be enforced implicitly by the unit framework.
Describe alternatives you've considered
The current design seems to use two alternatives:
- separate quantity types for contextually different uses of the same algebraic quantity, such as
Density and MassConcentration
-- NoInferredDivision as an escape hatch when the reverse operator is dimensionally valid but considered undesirable
These both work mechanically, but they create an inconsistent model:
- the quantity graph is no longer cleanly algebraic
- operator availability becomes partly editorial
- users cannot reliably reason from accepted forward relations to their reverse forms
That makes the framework less predictable and introduces special cases that exist “just because”.
Additional context
The issue is not that these suppressed operators are invalid. The issue is that UnitsNet currently accepts the forward relation, but then withholds some of its valid consequences based on taste or intuition.
For example, if this relation is accepted:
"Area.SquareMeter = KinematicViscosity.SquareMeterPerSecond * Duration.Second"
then Area / Duration -> KinematicViscosity is algebraically valid.
Likewise, if this relation is accepted:
"Ratio.DecimalFraction = Area.SquareMeter * ReciprocalArea.InverseSquareMeter"
then Ratio / Area -> ReciprocalArea is algebraically valid.
Suppressing those inverses makes the framework less symmetric and harder to reason about.
Similarly, Density and MassConcentration look like a context split over the same algebraic quantity rather than genuinely distinct quantity roots.
My concern is that these choices make UnitsNet harder to understand as a coherent units framework, because they replace algebraic closure with ad hoc context-sensitive decisions.
Is your feature request related to a problem? Please describe.
UnitsNet currently appears to mix two different design models:
That creates two related problems:
A concrete example of the first is
DensityandMassConcentration.They are both defined as mass per unit volume:
They have:
KilogramPerCubicMeterM = 1, L = -3So algebraically they are the same quantity, with the distinction belonging to usage context rather than the unit system itself.
A concrete example of the second is the use of
-- NoInferredDivision, for example:These relations are accepted in the forward direction, but their algebraically valid inverses are suppressed because the inferred reverse operators were considered unintuitive or ugly.
That makes the framework harder to reason about, because valid consequences of accepted relations are not always available.
Describe the solution you'd like
I’d like UnitsNet to prefer algebraic closure over assuming usage context.
More specifically:
Quantity identity should be determined algebraically first.
If two quantities have the same defining ratio form, dimensions, and unit algebra, they should not exist as separate root quantity types purely because they are used in different domains.
Accepted relations should be closed under their valid inverses by default.
If a multiplication relation is valid enough to exist, its inferred division operators should not be suppressed simply because the reverse expression seems unintuitive.
If domain-specific naming is important, that should be modeled explicitly as aliasing or semantic specialization, not by duplicating the algebraic root quantity or selectively removing valid operators.
In short: usage context should belong to the caller’s domain model, not be enforced implicitly by the unit framework.
Describe alternatives you've considered
The current design seems to use two alternatives:
DensityandMassConcentration-- NoInferredDivisionas an escape hatch when the reverse operator is dimensionally valid but considered undesirableThese both work mechanically, but they create an inconsistent model:
That makes the framework less predictable and introduces special cases that exist “just because”.
Additional context
The issue is not that these suppressed operators are invalid. The issue is that UnitsNet currently accepts the forward relation, but then withholds some of its valid consequences based on taste or intuition.
For example, if this relation is accepted:
"Area.SquareMeter = KinematicViscosity.SquareMeterPerSecond * Duration.Second"then
Area / Duration -> KinematicViscosityis algebraically valid.Likewise, if this relation is accepted:
"Ratio.DecimalFraction = Area.SquareMeter * ReciprocalArea.InverseSquareMeter"then
Ratio / Area -> ReciprocalAreais algebraically valid.Suppressing those inverses makes the framework less symmetric and harder to reason about.
Similarly,
DensityandMassConcentrationlook like a context split over the same algebraic quantity rather than genuinely distinct quantity roots.My concern is that these choices make UnitsNet harder to understand as a coherent units framework, because they replace algebraic closure with ad hoc context-sensitive decisions.