hep::velocity not a child of hep::speed?

[sebsassi]

In ISQ isq::velocity is a child of isq::speed, allowing implicit casts from isq::velocity to isq::speed, or quantity_cast the other way around. In the HEP system, however, hep::speed and hep::velocity are two completely independent quantities.

This seems like a bug, because my understanding is that the HEP system should model a similar but independent system to ISQ. I would therefore expect changing namespace from isqand si to hep to just work, but it doesn't seem to. Certainly, speed and velocity should be related quantities.

I would like to know if there is any rationale behind this decision.

This becomes an issue when dealing with vectors, because if I wanted to construct a velocity from a speed and a direction, I would do (I don't know if there is a better approach)

const my_vector_type my_direction = {std::sin(1.0)*std::sin(2.0), std::sin(1.0)*std::cos(2.0), std::sin(1.0)};
const quantity my_speed = speed(1.0*m/s);
const quantity my_velocity = quantity_cast<velocity>(my_speed*my_direction);

This works just fine using the isq and si namespaces, but not using the hep namespace, because the quantity_cast is forbidden. Of course I can do

const quantity my_velocity
    = quantity(my_speed.numerical_value_in(decltype(my_speed)::unit)*my_direction*velocity[decltype(my_speed)::unit])

But this is horrible to write and abandons the compile time safety of the units, so surely it cannot be the intended approach.

[mpusz]

Hi @sebsassi 👋

Thanks for using the library. You're probably the first confirmed HEP user 😉 If you're willing, I'd love an Usage Experience report, now or once you've settled in.

First, sorry for the late reply. When you submitted this, I was in the middle of implementing polar and spherical vector facades, which suit your use case perfectly. I thought I would finish it sooner, but it required more infrastructure work than I initially expected (we got the utility module, I had to submit updates to the Compiler Explorer integration and wait for them to be shipped). But in the end, it is done 😉

Yes, in HEP velocity should derive from speed just as in ISQ, and I've fixed that. Thank you for reporting that 🙏

However, the direction you'd probably want is not the quantity_cast. You should not convert between different quantity characters, and V3 will make that a hard error. speed is the scalar magnitude of the vector velocity. Going from one to the other is a geometric operation (magnitude × direction), not a cast.

A couple of notes on the example itself:

• my_speed * my_direction reads backward - you're attaching a dimension to a bare vector via a 1 m/s identity. my_direction * m / s does the same thing directly.
• Your my_direction isn't actually a unit vector/direction: its length is √2·sin(1) ≈ 1.19, and the components don't follow the usual (sinθ cosφ, sinθ sinφ, cosθ) convention (the z uses sin where it should be cos, and x/y are swapped). So it isn't the θ=1, φ=2 direction, it looks like - exactly the kind of silent slip that motivates the next point.

As stated above, over the last few days, I've been working on polar/spherical vector facades. With them, your example is just a magnitude and two angles, and you get a proper velocity vector with no cast and no hand-written trig:

const quantity my_speed = isq::speed(1.0 * m / s);
const utility::spherical_vector v_spherical{my_speed, 1.0 * rad, 2.0 * rad};   // speed + inclination(θ from +z) + azimuth(φ from +x)

// a genuine velocity vector — no quantity_cast, no character crossing
const quantity<isq::velocity[m / s], utility::cartesian_vector<double, 3>> v_cartesian = v_spherical.to_cartesian();

The magnitude stays a speed, to_cartesian() hands back a vector that converts cleanly into velocity, and the (θ, φ) convention is fixed so the components can't drift out of sync. You can check it out here: https://godbolt.org/z/PKvb57vhx. Is this what you were looking for?

[mpusz]

More about polar and spherical coordinates can be found here: https://mpusz.github.io/mp-units/latest/how_to_guides/advanced_usage/polar_and_spherical_coordinates

[mpusz]

Also, your question reminded me that I had been planning to write a dedicated post about HEP based on our Seminar a few months ago. Here it is: https://mpusz.github.io/mp-units/latest/blog/2026/07/08/bringing-safety-to-hep/.

[sebsassi]

Thank you for the response. I've been planning on writing a report on my experience with the library eventually. I hope I can offer some unique perspective, since my work exists at the intersection of elementary particle physics and astrophysics. So, I regularly have to deal with mixed units, where my masses and energies are in some multiple of eV, but passage of time is measured in days.

But as of now, it's only been a bit over two weeks since I thought my project probably needs compile-time unit checks. I will need more time, but I will definitely give a report on my experience, because I'm overall excited about the premise of this library and wish to see it succeed.

As for the solution to what I want to do, the real issue that led me here was a bit different than the one I gave as an example. The specific problem had to do with the velocity of a planet on an elliptical orbit, something like (schematically) speed*{-sin(angle), e + cos(angle), 0}. It's technically possible to rewrite this using spherical vectors, but that would lead to unnecessary evaluation of trigonometric functions and would give an overly verbose expression that obscures the intent.

More simply still, I have places in my code, where I would really like to write things like, say {0, -speed, 0}. (This is arguably a distinct issue from the previous one, but in the spirit of it.)

An example I don't have in the current project, but that I've dealt with before is sampling along a radial line from the origin. In that case I have a single unit vector, and a collection of magnitudes I want to multiply with it to get a collection of vectors. Not ideal to use spherical vectors, because that could lead to unnecessary re-evaluation of trigonometric functions for every magnitude.

The point being, there are various situations that are conceptually of the form vector = magnitude*unitless_vector. In an ideal world, I would like for this to just work, with the multiplication automatically promoting the result to the correct vector quantity corresponding to the magnitude. That may not be feasible, but what I'm really looking for is the simplest way to express this concept, supposing I know my magnitude quantity, and my target vector quantity.

In other words, how would I make the last line here do the correct thing?

const my_vector_type my_direction = some_function_i_have_no_control_over();
const quantity my_speed = some_other_function_i_have_no_control_over();
const quantity my_velocity = my_speed*my_direction;

[mpusz]

Thanks for the detailed follow-up.

but that would lead to unnecessary evaluation of trigonometric functions and would give an overly verbose expression that obscures the intent.

Please note that my spherical vectors are only facades and they do not provide all the arithmetic exactly to prevent this noise. You need to convert to a Cartesian vector once and stay there as long as you want. For a direction that is already Cartesian, like your orbit case, you should not reach for spherical vectors at all.

vector = magnitude*unitless_vector

This turned out to be a real bug on our side, and I have fixed it (should be online in the Compiler Explorer tomorrow). Scaling a Cartesian vector by a scalar quantity now produces a vector quantity. We need to name the target quantity, because the library cannot know that a scalar speed becomes a velocity:

const quantity speed = isq::speed(10 * m / s);
const utility::cartesian_vector dir{-std::sin(a), e + std::cos(a), 0.0};
const quantity my_velocity = isq::velocity(speed * dir);

To make it compile, if the vector comes from a type you do not control and it has its own greedy operator*, construct the quantity directly instead of going through operator*:

quantity<isq::velocity[m / s], my_vector_type> my_velocity{my_direction * mag, m / s};

or use delta helper.

{0, -speed, 0}

It might be a different problem. Please check: https://mpusz.github.io/mp-units/latest/blog/2026/06/23/units-meet-linear-algebra-two-approaches-two-problems/

The form that works today is isq::velocity(cartesian_vector{0.0, -1.0, 0.0} * speed).

Dedicated unit vectors (magnitude = 1) are still planned for V3. They are not available in the framework for now.