Provide support for non-negative quantities

[mpusz]

ISO 80000 explicitly specifies quantities that have to be non-negative (width, thickness, diameter, radius).

Some of the quantities are implicitly defined as non-negative. For example, "path length" is defined as hypot(dx, dy, dz). Others are defined as the magnitude of a vector which also is always non-negative.

Some quantities are also explicitly defined as signed (i.e. height), so they should not be treated as a norm(position_vector).

[mpusz]

We should probably provide some exceptions from the rules for engineering purposes. For example, speed is defined as a magnitude of velocity which implies that it is non-negative.

For engineering purposes, speed probably should be defined as length / time which improves usability. For example, we can easily calculate height / length without mandating users to use a linear algebra library. In such a case a negative height can result in a negative speed.

[JohelEGP]

What does the library need to do,
besides permitting user-defined representation types that can catch negative values?

[mpusz]

The check implementation part is easy. Just do the compile-time branch with gsl_Assert().
However, first, the logic (when and where) has to be figured out. Then we have to find out how to store the information about this in a derived quantity based on the quantity equation.

[JohelEGP]

I think I have an answer.

Either we do nothing,
or provide a way to opt-into having a non-negative quantity type.

For example, I wrap a width and a height in a Cartesian vector.
I should be able to add and subtract these values without triggering assertions.
Sometimes, the Cartesian vector represents a size,
in which case both of the components should be non-negative.
In this case, the width and height components are equally constrained.
So there isn't anything particularly special about width.

It seems to me that ISO/IEC 80000 sometimes calls out special cases like this.
However, that shouldn't prevent us from applying the maths to manipulate these values.
As for

or provide a way to mark a given value's type as non-negative

it seems to me that we actually want an interface that both applies abs when first converting the quantity
and updates the quantity_spec to require the numerical value to be non-negative from there on.
So I can do

Quantity_of<width> auto q = (entity1.pos.x - entity2.pos.x).non_negative();

when I require the result to be the width that is non-negative,
and an equivalent interface to easily name such a constrained type.

It seems to me that ISO/IEC 80000 sometimes calls out special cases like this.

Others include quantity difference and quantity point pairs.
So where we might use quantity<time[s]> and quantity_point<time[s]> as a difference and point, respectively,
ISO/IEC 80000 might actually have different names for those.
For example, I get the impression that these come in groups of points and corresponding difference:

• Position vector and displacement (Part 3, §3-1.10, §3-1.11).
• Electric potential, electric potential difference, and voltage (Part 6, §6-11).

There may be a few others, but I don't remember.
I think I may have mentioned this before.
I also don't remember if V2 does anything in particular with this information.

[mpusz]

For example, I wrap a width and a height in a Cartesian vector.
I should be able to add and subtract these values without triggering assertions.

Sure, please note that subtracting width from height is a length that is not constrained by itself.

ISQ defines only width, thickness, diameter, and radius to be non-negative. Additionally, probably quantities that are defined as magnitudes of vectors could be non-negative as well.

However, subtracting width and width will give you width as a result, and we have to decide what to do with that... 😉

So I can do

Quantity_of<width> auto q = (entity1.pos.x - entity2.pos.x).non_negative();

when I require the result to be the width that is non-negative,
and an equivalent interface to easily name such a constrained type.

I actually never thought of that, but I am not sure if that is needed. The temporary result probably does not need constraints. The check has to be done in the width constructor if the value is non-negative anyway.

I also don't remember if V2 does anything in particular with this information.

I am not sure if we should constrain some ISQ types to be used only for either quantity or quantity_point. It could be too much, but maybe we should discuss this option in a dedicated issue? Another question is who would be able to properly identify those?

[JohelEGP]

For example, I wrap a width and a height in a Cartesian vector.
I should be able to add and subtract these values without triggering assertions.

Sure, please note that subtracting width from height is a length that is not constrained by itself.

I meant the vector values, which does the component-wise operation
(so no width plus height, but rather width plus width and height plus height).

[JohelEGP]

However, subtracting width and width will give you width as a result, and we have to decide what to do with that... 😉

This is why I answered

Either we do nothing,
or provide a way to opt-into having a non-negative quantity type.

I forgot that to mention that it might just be the case of a missing abstraction.
Which is why I mentioned enhancing quantity_spec to recognize the constrained case.
We still want to be able to have differences and points of "negative" quantities that aren't actually constrained.
If we force the property for all uses of the quantity, it becomes engineering unfriendly.

[mpusz]

Please note that isq::height can be negative.

Probably, you are abusing isq::width for your coordinate needs. Width is something that you may measure with a
caliper. There is no physical way for it to be negative. Maybe you should derive your own quantity_spec from isq::length to denote X axis?

[JohelEGP]

Yeah, I'm considering that.
I need to do it for depth, anyways, which in ISQ is a synonym for height.
However, I'm not convinced that my abuse of width means that my opinions on how it should be handled by the library are invalid.
If it's constrained, the only reasonable way to change width values is to work on lengths before converting to widths.

[mpusz]

I would do something like:

QUANTITY_SPEC(pos_x, isq::length);
QUANTITY_SPEC(pos_y, isq::length);
QUANTITY_SPEC(pos_z, isq::length);

[mpusz]

If it's constrained, the only reasonable way to change width values is to work on lengths before converting to widths.

Yes, if we really want to subtract two widths measured by the caliper and we really need to subtract the bigger value from the smaller one we would probably need something like that:

QuantityOf<isq::length> auto q = isq::length(width1) - isq::length(width2);

which I think may have some sense in a "twisted" physical way 😜

[JohelEGP]

I also don't remember if V2 does anything in particular with this information.

I am not sure if we should constrain some ISQ types to be used only for either quantity or quantity_point. It could be too much, but maybe we should discuss this option in a dedicated issue? Another question is who would be able to properly identify those?

I remember that we did discuss this before.
I think it was something about how a quantity difference can have different associated points.
The associated points could be different by definition, and thus not share an origin among themselves.
And I think I concluded that a quantity difference doesn't necessarily have a default associated point.
So it's the user who should opt-into using the correct quantity point for their use case.