Is the library multi-dimensional, dimension-less?

[viboes]

Could you confirm the current implementation is uni-dimensional?
If yes,

Do you plan to manage with multi-dimensions?

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

[mpusz]

Hi Vincente, First of all thanks for the interest in my project. I would love to have an official physical library library in the C++ Standard Library. This is my modest attempt to create one. It is only in a startup phase for now as I did not have too much time to work on it yet. I will come back to it after San Diego and Meeting C++. I am open to contributors, feature requests and feedback :-) I want it to cover the most important needs of C++ industry. Best Mat śr., 31 paź 2018, 22:34 użytkownik Vicente J. Botet Escriba < notifications@github.com> napisał:

…

Could you confirm the current implementation is uni-dimensional? If yes, Do you plan to manage with multi-dimensions? Do you plan to manage with dimension-less quantities? Just a counter, as counting the number of potatos. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAe5lMAAYHDD39fY5A90dCmbaCBib7b-ks5uqof9gaJpZM4YFz1E> .

[mpusz]

Could you please describe what you mean by multidimensional? I support velocity already... I am not sure if dimension-less quantities have much sense in the industry and how they differ from strong typedefs. I would need to think about it a bit more. Could you please provide an example of some physical multidimensional calculation that would use such quantity? Best Mat The next milestone for me is to handle temperature. Best Mat pt., 2 lis 2018, 06:59 użytkownik Mateusz Pusz <mateusz.pusz@gmail.com> napisał:

…

Hi Vincente, First of all thanks for the interest in my project. I would love to have an official physical library library in the C++ Standard Library. This is my modest attempt to create one. It is only in a startup phase for now as I did not have too much time to work on it yet. I will come back to it after San Diego and Meeting C++. I am open to contributors, feature requests and feedback :-) I want it to cover the most important needs of C++ industry. Best Mat śr., 31 paź 2018, 22:34 użytkownik Vicente J. Botet Escriba < ***@***.***> napisał: > Could you confirm the current implementation is uni-dimensional? > If yes, > > Do you plan to manage with multi-dimensions? > > Do you plan to manage with dimension-less quantities? Just a counter, as > counting the number of potatos. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#2>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAe5lMAAYHDD39fY5A90dCmbaCBib7b-ks5uqof9gaJpZM4YFz1E> > . >

[mcbeth]

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)

[mpusz]

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>

[mpusz]

For (2) see #27

[i-ky]

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.