Should quantity_point and kind be extended with new use cases?

[mpusz]

I just refactored glide_computer example. Doing this I realized that we might want to provide some extensions to our library.

[mpusz]

Custom expressions to build a quantity

Should it be possible to add distance and height vectors and obtain a derived vector in 3D space?

https://github.com/mpusz/units/blob/cdba0cdbc4d20254e907a002f131fe5160676c4d/example/glide_computer.h#L201-L205

[dwith-ts]

You mean this here: Vector3d displacement{DX{Zero}, DY{quantity_metre_2}, DZ{Zero}}; ?

For a 3d point it might seem overkill (and could of course be left out when implementing this), but think about

• having dozens of different coordinate frames (ok, there the type of your variable should still give you the information in which frame the vector is)
• you could just as easily create a vector that has VX, AX, VY, AX (velocity and accelerations in x and y direction) then a MyVectorType vec{VX{q1}, AX{q2}, VY{q3}, AX{q3}} prevents users from mixing up the order and also enables the usage of something similar to quantity_kind's (these tag types are very similar to quantity_kinds); they are not identical as you might also have e.g. an information vector (used in kalman filters / information filters) which has its units inverted, meaning VX would need a quantity of unit [s/m]. By using tag types, the identical tag type can be used for a normal and an information vector. With quantity_kinds, a new kind would be needed in this case.

[JohelEGP]

You mean this here: Vector3d displacement{DX{Zero}, DY{quantity_metre_2}, DZ{Zero}}; ?

Yes.

[dwith-ts]

Cross-referencing to #244 (comment) , your suggestion get<0>(vec) would simply be a vec.coeff<DX>() with what I am proposing here which is a pretty nice interface.

[JohelEGP]

That could work like std::tuple does. It works if it is unique, otherwise it's ill-formed.

[dwith-ts]

That could work like std::tuple does. It works if it is unique, otherwise it's ill-formed.

Yes, of course. Duplicates in the tag types are detected at compile time. Additionally, there is no way to do an out-of-bounds access when using these tag types. It is guaranteed to be a valid element access if it compiles.

[mpusz]

Different representation for quantity and quantity_point

Does it makes sense to make quantity_point of length for some kind to be expressed in latitude and longitude:

https://github.com/mpusz/units/blob/master/example/geographic.h#L32-L48

but a quantity of length for the same kind to be expressed in distance and bearing calculated with things like:

https://github.com/mpusz/units/blob/cdba0cdbc4d20254e907a002f131fe5160676c4d/example/geographic.cpp#L29-L53

[JohelEGP]

Does it makes sense to make quantity_point of length for some kind to be expressed in latitude and longitude:

I was wondering why you didn't use quantity kinds. latitude and longitude could be quantity_point_kinds. The way it works right now, though, you'd need to first define a kind for them. Perhaps latitude_difference and longitude_difference.

[JohelEGP]

By the way, have my comments addressed what you intended? You title this "Different representation for quantity and quantity_point", but I don't think you were referring to rep. Perhaps you meant something more like linear_algebra::vector<distance> or distance<linear_algebra::vector>?

[mpusz]

I actually meant different representations:

• quantity_point<lat_lon>
• quantity<dist_bearing>

The only tricky point here is quantity<dist_bearing> + quantity<dist_bearing>` which does not have to be positioned on a straight line which again moves us to the first question #242 (comment).

[mpusz]

I was wondering why you didn't use quantity kinds. latitude and longitude could be quantity_point_kinds. The way it works right now, though, you'd need to first define a kind for them. Perhaps latitude_difference and longitude_difference.

Yeah, I could use those but I didn't want to bend towards any solution for now and discuss with you what is the best approach to address such a use case. There are a lot of apps that could benefit from quantities algebra based on GPS coordinates.

[JohelEGP]

Hmmm... Do you want to avoid mixing quantity_point<dim, unit, latitude> with quantity_point<dim, unit, longitude>? It seems that using the representation type for that is not a good approach. That's what quantity_kinds are for. Or, perhaps, quantity_kinds were never necessary if annotating the rep were another possibility. That, however, would require having such a rep and thus this type of kind couldn't use arithmetic types.

Did I understand your purpose here?