How to handle type level difference in coordinate/orientation angle types?

[Cazadorro]

Prior to using mp-units, we developed our own angle library internally to deal with unit safety and converting between different coordinate systems (geodetic , NED, LLA, LLHAE, ECEF etc...). We've now used mp-units for a long time, and while we use it for a lot of other units, we've not found it possible to use practically with basically anything that deals with world coordinates/orientation and coordinate-based angles of measure.

Lets start with what mp-units appears to provide:

• radians, degrees, gradians, cycles/revolutions, steradian, and derived units from these.

In the coordinate/orientation world however, these angles are not this simple.

In the simplest case, such as with spherical coordinates, we take a simple azimuth, elevation coordinate on a 2D sphere, Azimuth angle can be handled by radians/degrees fine, however, elevation angle does not behave like azimuth. Elevation angle is reflected at the peaks of the sphere. We represent this as an non-type template passed into our angle types in our angle library, where this angle regime is called "symmetric". This property for elevation basically says at past 90 degrees, we go to 89 degrees instead of 91 degrees.

Latitudinal coordinates also have this very same property symmetry, and unlike an arbitrary sphere, you can't just make believe and pretend you can go past 90, there isn't a longitude that corresponds to a value larger than 90 degrees.

Additionally, there's a different type of reflection, one that most people are used to, that being a system where going past 0 goes negative, until it wraps around to -180 degrees and flips to 180. This is often used with azimuth (what we will call geometric azimuth, for reasons that will become clear soon) interchangeably with 0->360 wrapping. However, in the coordinate world we can't do this. In our angle units library, we called this "mirrored" wrapping,

In addition There's different ways of representing latitude and longitude that wrap differently depending on the source. Some LL systems use positive only longitude, so there is no mirroring. We call a 0->360 wrapping (or equivalent 0->2*pi) "full" wrapping.

Along with symmetric, mirrored, and full wrapping, the default wrapping mode is "none", which enforces no wrapping scheme and is also desirable in many situations.

This alone calls for a type level encoding of each of the wrapping schemes in order to convert/compare different sources of different formats of coordinate angles. But this further is exacerbated by heading or bearing angle.

Under a geometric azimuthal scheme, 90 degrees is the equivalent of north, or forward, and as you go counter clockwise on a circle, the angle increases. However, there are a multitude of different ways of treating the north angle even on a single azimuth plane. In a different scheme we commonly found, often associated with "heading", otherwise known as "bearing". Under this regime, the zenith/forward direction becomes zero, going counter clockwise is negative, requiring a conversion in the form of 90degrees - angle to go back and forth between geometric azimuth and bearing. We say geometric azimuth here, because there are other azimuth schemes that move 0 to forward instead of to the right, but maintain counter clock wise positive (heading azimuth).

We've had to separately encode bearing along side the mirroring modes, as some units use both.

How would we encode these things inside of mp-units?

[mpusz]

Hi @Cazadorro!

Thanks for your interest in the library and great feedback. Until recently, I was unaware of those use cases, but they were brought to me independently of you last week. I work on the solution now. See https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/the_affine_space/#range-validated-quantity-points. It is not the final version, and I already have some changes on my local computer, but it would be great if you could provide feedback on whether it is going in the right direction.

I would love to work with you on a new domain-specific example or how-to guide for our docs:

• example would be simplified, but still a production-like code from your domain
• how-to guide would teach people how to model this.

I also discussed with others that we would really benefit from creating a geography-centric system of quantities and units, so people do not have to reinvent the wheel. As you probably know, I have a geography header. Let's improve it and promote it to core or systems from examples.

We can start with some code in Compiler Explorer and build on it from there. Can you help to improve here?

[mpusz]

Sure, this is very similar to our named_constants. But indeed they do not have to be named here, so we could just do:

template<>
inline constexpr auto mp_units::quantity_bounds<geographic::east> =
  mp_units::wrap_to_range{mag<-180> * mp_units::si::degree, mag<180> * mp_units::si::degree};

instead of

template<>
inline constexpr auto mp_units::quantity_bounds<geographic::east> =
  mp_units::wrap_to_range{-180 * mp_units::si::degree, 180 * mp_units::si::degree};

I am unsure if that will make the users happier, but it would work as you described.

mp-units is unlikely to ever get for philosophical reasons (i.e., an aversion to shapeshifter types such as Zero)

Well, it grows in me ;-)

mp-units/src/core/include/mp-units/overflow_policies.h

Line 218 in 2eb094c

struct zero_quantity_t {

Maybe I will promote this to the public type. I need some time to play with it first, though.

[Cazadorro]

I'm trying to get started I thought the best method was to test this out with a fork, but I'm used to using this through VCPKG and I'm running into some weird stuff with MSVC. Merely including #include <mp-units/systems/si.h> gets me

\mp-units\src\core\include\mp-units/framework/quantity_spec.h(344): error C2220: the following warning is treated as an error
\mp-units\src\core\include\mp-units/framework/quantity_spec.h(344): warning C4296: '>': expression is always false

which is lead me to see this line in quantity spec:

template<typename... NumQs, typename... DenQs>
inline constexpr bool factors_are_non_negative<type_list<NumQs...>, type_list<DenQs...>> =
  (sizeof...(NumQs) + sizeof...(DenQs) > 0) && (factor_is_non_negative<NumQs> && ...) &&
  (factor_is_non_negative<DenQs> && ...);

}  // namespace detail

specifically "(sizeof...(NumQs) + sizeof...(DenQs) > 0)" which makes me think MSVC thinks this is applying sizeof to types instead of parameter pack size of, since this would be true (since all types must have non zero size). I disabled /w14296 for my usages, but I also found when trying to reproduce this bug in godbolt, not only could I not do so (presumably with out including the rest of the infastructure from mp-units) but there were other obvious cases where MSVC would just refuse to warn (such as... actualy doing (sizeof(T) + sizeof(U) > 0)) so I'm really not sure what is going on. Note I'm using the latest release (but not the preview build) of the 2026 build tools, and the bugs mentioned in the docs with MSVC have been fixed and released since january.

I had to also force fmtlib to be used instead of std::format even though it was availible.

After disabling that warning and using fmtlib instead of std::format, I was able to compile a bunch of things, but attempting to run the unit_tests_runtime (yes I know I don't need to run that, but I ran into other new compilation issues with this geographic stuff) and ran into the private member in double_width_int not being exposed, so I added a new check in fixed_point.h and added "!MP_UNITS_COMP_MSVC" next to the GCC guards.

Then I ran into constrained_test.cpp having another warning with

\mp-units\test\runtime\constrained_test.cpp(46) : error C2220: the following warning is treated as an error
\mp-units\test\runtime\constrained_test.cpp(46) : warning C4702: unreachable code
\mp-units\src\core\include\mp-units\framework\quantity_point.h(298) : warning C4702: unreachable code

which is complaining about the return q from this I think:

// Apply bounds to q (expressed relative to PO's origin frame).
// Uses compile-time lookup to find the bounds owner and its offset from PO — at most a
// single runtime translate/apply/un-translate with no recursive function calls.
template<PointOrigin auto PO, auto R, typename Rep>
constexpr quantity<R, Rep> enforce_bounds(quantity<R, Rep> q)
{
  if constexpr (HasQuantityBounds<std::remove_cvref_t<decltype(PO)>>) {
    // Direct bounds on PO — apply without any translation.
    return quantity_bounds<PO>(q);
  } else if constexpr (any_ancestor_has_bounds(PO)) {
    // No direct bounds — locate the bounds-owning ancestor and its cumulative offset,
    // both resolved entirely at compile time.
    constexpr auto bpo = bounds_po_for(PO);
    constexpr auto off = bounds_offset(PO);
    // Single flat: translate to owner's frame, apply policy, translate back.
    return quantity_bounds<bpo>(q + off) - off;
  }
  return q;
}

I tried disabling all warnings and I got hung up on compiling distribution_test.cpp

Switching to clang-cl seemed to work though. but we can't stick to clang-cl long term because of CUDA not supporting clang-cl as a host compiler (AFAIK).

[mpusz]

Yeah, I'm sorry to hear about your problems. Unfortunately, MSVC is a really bad compiler that still has many issues when compiling the library, even in C++20. I escalated those issues many times over the years to the highest-level figures responsible for MSVC, and we still have them. I really don't know what we could do to improve here. Maybe you can submit more bugs to MSVC stating that it does not compile correct C++20 code. Maybe more users complaining will prompt Microsoft to prioritize the work...

[Cazadorro]

Yeah, I'm sorry to hear about your problems. Unfortunately, MSVC is a really bad compiler that still has many issues when compiling the library, even in C++20. I escalated those issues many times over the years to the highest-level figures responsible for MSVC, and we still have them. I really don't know what we could do to improve here. Maybe you can submit more bugs to MSVC stating that it does not compile correct C++20 code. Maybe more users complaining will prompt Microsoft to prioritize the work...

Submitting bug reports seems to work (as it fixed other issues though it took a loooong time), but I can't help but feel that maybe MSVC should be taking the initiative to fix issues in a popular well known c++ library that's been in development for years and is up for possible standardization that works fine on other compilers with out relying on open source contributors to spend hours create MVCEs for their often nonsensical compiler hiesenbugs only for new bugs to appear once those are fixed.

This library should be a part of their own compiler testing framework, I wonder if there's a way to just submit a bug report for "Hey, every other compiler can compile this library in C++20 mode, MSVC can't" as it's own bug. It may also be useful to talk to people to get in contact with the compiler team, or get in contact with the people who know those people to see if it's possible for them to take ownership of these issues with out a million back and forths.

[mpusz]

It may also be useful to talk to people to get in contact with the compiler team, or get in contact with the people who know those people to see if it's possible for them to take ownership of these issues with out a million back and forths.

I am an active voting member of the ISO C++ Committee. I talk to both MSVC developers and product owners regularly, asking to fix the compiler. I really can't do much more :-(

[mpusz]

BTW, can you share your usage experience with the library? You can do it now or wait until we finish with this request.

[mpusz]

Hi @Cazadorro, I believe I finished the last feature needed to model your case properly today. Please check out https://mpusz.github.io/mp-units/latest/users_guide/framework_basics/the_affine_space/ and the definitions below in geographic.h:

mp-units/example/include/geographic.h

Lines 147 to 163 in cd578a9

	template<typename T = double>
	using latitude = mp_units::quantity_point<geo_latitude[mp_units::si::degree], equator, T>;
	template<typename T = double>
	using longitude = mp_units::quantity_point<geo_longitude[mp_units::si::degree], prime_meridian, T>;
	template<typename T = double>
	using elevation = mp_units::quantity_point<geo_elevation[mp_units::si::degree], horizon, T>;
	template<typename T = double>
	using azimuth = mp_units::quantity_point<geometric_azimuth[mp_units::si::degree], east, T>;
	template<typename T = double>
	using bearing = mp_units::quantity_point<geo_bearing[mp_units::si::degree], north_cw, T>;
	template<typename T = double>
	using heading = mp_units::quantity_point<heading_azimuth[mp_units::si::degree], north_ccw, T>;

mp-units/example/include/geographic.h

Lines 331 to 335 in cd578a9

	template<typename T>
	class position {
	public:
	latitude<T> lat;
	longitude<T> lon;

Of course, it is still a simple mode, and contributions are welcome. Please let me know how it works for you.