The semantics of operator==

[mpusz]

We all probably agree that various entities in this project should be comparable with an operator==. The most obvious case here is the comparison of quantities:

static_assert(1 * N == 1 * kg * (1 * m / s2));
static_assert(1 * isq::force[N] == 1 * isq::mass[kg] * (1 * isq::acceleration[m / s2]));
static_assert(isq::force(1 * N) == isq::mass(1 * kg) * isq::acceleration(1 * m / s2));

However, as all other entities (dimensions, units, quantity specifications, and references) in the library are defined as values, we should probably also allow comparing them. Some are easy and consistent:

static_assert(N == kg * m / s2);
static_assert(isq::force.dimension == isq::mass.dimension * isq::length.dimension / pow<2>(isq::time.dimensions));

However, this is not true for quantity specifications and references that use them:

static_assert(isq::force != isq::mass * isq::length / pow<2>(isq::time));
static_assert(isq::force[N] != isq::mass[kg] * isq::length[m] / pow<2>(isq::time[s]));

But:

static_assert(implicitly_convertible(isq::force, isq::mass * isq::length / pow<2>(isq::time)));
static_assert(implicitly_convertible(isq::mass * isq::length / pow<2>(isq::time), isq::force));

I think it has sense and is reasonable for people knowing the domain.

However, one could argue that the quantity should compare equal only if all its components compare equal as well.

Should we change the current behavior? Do we have any ideas on how to improve here?

[JohelEGP]

Please, clarify the title to include which operator==.

Quantity reference is suppose to represent the quantities described by ISO/IEC 80000.
Each row in its tables represents a unique quantity*.
So, if operator== is to exist, the homogeneous one should return true, and the heterogeneous one false.

*: Except where they are repeated in other parts (confirmed by matching descriptions), which might be a vestige of earlier editions.

[mpusz]

Yes, this it the main problem here. In the title I meant operator== in the entire mp-units library. This means that we need to address that for all the entities as stated in the description.

The main questions here are:

1. Should the op== have consistent behavior implementation for all entities, or should it have different implementations for each of them?
2. If two quantities compare equal should all of the components of such quantities (dimensions, units, quantity specifications, and quantity references) also compare equal?

[JohelEGP]

1. Please, explain what you mean.
2. Yes, but exclude the quantity specification (or reference), which is what represents a "quantity" (not a concrete value, but the concept).
   In my reply above, I suspect I used "reference" instead of "specification".

[mpusz]

Thanks! I do not think that pt 1 needs answering anymore.

It seems that we agree that quantity specification is special and should have a different behavior even if the quantity using it compares equal.

[chiphogg]

I'll preface by confessing once again that my brain is very much stuck in the "dimensions-and-magnitudes" world that Au inhabits, and any finer distinctions are liable to lose me rather quickly. 🙂

For quantities, I've always thought it nice if 1 * m == 100 * cm. Au behaves this way, and I can't think of a single problem it's ever caused.

It's also true that we support 1 * m > 99 * cm, and 1 * m <= 101 * cm, and so on. I think mp-units does too. Granted, equality and inequality operators may be different in some ways, but if we support mixed units in the latter but not the former then I think it would be very surprising.

If we go beyond dimensions-and-magnitudes, I'm less sure how things should work. It seems as though if we have implicit convertibliity in either direction --- say, one is a length, and the other is some more-specialized length, like a radius? --- then we should continue to support implicit equality and inequality comparison. And that if the quantities are each more-specialized versions of some common type, but neither is implicitly convertible to the other, then this shouldn't compile.

As for non-quantity types: there are multiple possible concepts for what == might mean, but they are incompatible. Therefore, I think we should simply not provide them. operator== is syntactic sugar for these types, but the meaning of that syntax is ambiguous. We'll be better served with well named traits and/or functions, which can say by their names exactly what they mean.