Is the library multi-dimensional, dimension-less? about mp-units HOT 6 CLOSED

from mp-units.

from mp-units.

I'm reading between the lines on @viboes message, but I'm often dealing with cameras, and so go from radiance ph/(srm^2sec) to sensor counts through electrons. Neither photons, nor electrons, nor sensor counts appear in typical base unit lists, as they are counts of things (although we're usually interested in expected value, and so floating point values are allowed). It may be worth looking at the kinds of units astropy or YT supports?

Other obvious (to me) dimensionless quantities that are handy are the angle dimensionless quantities. I regularly encounter radians, degrees/minute/seconds, and hours/minutes/seconds as angle measures (ignoring the aforementioned solid angle)

from mp-units.

My current understanding of @viboes question is that there are 2 mixed abstractions here:

1. "Could you confirm the current implementation is uni-dimensional? If yes, Do you plan to manage with multi-dimensions?"

   I think that this question is not about dimensions in SI sense. SI defines dimensions as:

   Expression of the dependence of a quantity on the base quantities of a system of quantities as a product of powers of factors corresponding to the base quantities, omitting any numerical factors.

   In such a sense every sane physical units library is multi-dimensional as length, time, and velocity are separate dimensions in this sense.

   My understanding of this question is that we are talking here about i.e. space dimensions. For example, if I have a height and width (both quantities of dimension length) this library treats both as the same SI dimension and allows all operations on them with no restrictions. I believe that the notion of dimensions in space is orthogonal to this library and a new library could be provided to support this (taking double or units::quantity<units::metre> as a Rep parameter).

2. Do you plan to manage with dimension-less quantities? Just a counter, as counting the number of potatos.

   I know that other libraries implement a dimensionless quantity which basically is implemented as a quantity with an empty dimensions list. Such a quantity behaves differently than any other quantity class template instantiation in a way that it can be implicitly converted from/to scalars. In my opinion, this only complicates the design and implementation and provides the users a false immersion of safety (we are dealing here with a strong type, right?) (i.e. mach_number + refractive_index is a valid operation). This is why the library right now returns Scalar from division operation on the same dimensions (i.e. 4m / 2m == 2). This follows the idea of "If you behave like a scalar, just use scalar".

   However, as SI spec says:

   The measurement units and values of quantities of dimension one are numbers, but such quantities convey more information than a number

   I can revise that with returning a type that actually provides strong type safety with which mach_number + refractive_index will not compile. This, however, has some other issues so I am not sure if we should strive for this:

   auto q1 = 10mps * 2s;      // length
   auto q2 = q1 / 2m;         // dimensionless<length>
   auto q3 = 10mps * 2s / 2m; // dimensionless<velocity>

from mp-units.

For (2) see #27

from mp-units.

Could you confirm the current implementation is uni-dimensional?

I have a feeling that this wasn't a question about restricting operations with width and height, but more about vector quantities. Like, does the library allow us to have a 3-dimensional velocity vector in kph or do we have to create a vector with 3 components each being an independent quantity? If that's the case, I would point to a relevant discussion in #23.

from mp-units.