handling of vector quantities and linear algebra libraries

[rconde01]

I'm curious to your thoughts on how this applies beyond scalar quantities. How might this be combined with a linear algebra library like eigen?

[mpusz]

Hi, I do not have much experience with Eigen but I can imagine 2 approaches here:

1. quantity behaves like a numeric type so it can be easily used in other libraries as a vector of quantities.
2. quantity takes Rep as a template parameter and maybe it could be some vector representation there.

I asked @hatcat if he could take a look at it. Maybe we should cooperate while working on units and LA libraries...

[hatcat]

Sorry about the delay. I have an insane three weeks coming up (C++ Russia in St Petersburg, WG21 in Belfast, Meeting C++ in Berlin).

Looking through the quantity class I see a lot of LA-like stuff going on (although I am confused by operator/). I think both approaches are appropriate: would you like to schedule a telecon to refine the discussion about which would be more appropriate under which conditions?

[mpusz]

As it is only 2 weeks to Belfast now, maybe we should meet there and discuss possible approaches here?

[mpusz]

I met with linear algebra folks in Belfast and the outcome is that the current LA proposal will work great with units library :-)

The only thing missing in LA is matrix_cast<To>(From) and an extension point for casting which will be called by it and will allow calling units::quantity_cast<To>(from) for each element of the matrix.

We agreed that we will provide examples of how both libraries can cooperate with each other.

[rconde01]

Great to hear. I'm very interested in seeing some examples. Some thoughts I have at the moment:

• IIRC the LA proposal is about the base operation implementation. It would be good to know it also works for Expression-Template layers (e.g. Eigen, Blaze) which presumably could layer over that to avoid temporaries. I have no particular reason to think it wouldn't work in this context, but I appreciate the possibility that there might be a blocker there.
• did your discussions include mixed units or only uniform units?
• maybe it's straightforward, but i wonder about unit erasing operations like diagonailization
• I suppose something like a rotation would be a unitless transformation?

Thanks for your work!

[dwith-ts]

@rconde01 : A rotation is a linear transformation between vector spaces and as such is very similar to a jacobian matrix (actually the jacobian of an isometry transformation is the rotation matrix).
=> rotations have unit-less entries

[dwith-ts]

Regarding the idea to put physical units inside a LA library:
This is a godd idea, but I presume that this can break pretty easily because all matrix operations would need to be supported.

This might be easy (if the linalg library is designed very specifically for this) for something like the dot product of 2 vectors where the return type is just decltype(vecA(0) * vecB(0)).

If you have matrices, there are very few matrices where you can get along by just specifying one element unit. A covariance matrix with unit [m^2] for example is something completely different than a Jacobian matrix with unit [m^2] and the allowed operations are also different for a covariance vs. a jacobian.

@rconde01 's question with a rotation is again another level where you would ideally also need support for specifying coordinate systems, not only for si-units.

Furthermore, the distinction between points and displacement vector is important: for example, a position vector can only be transformed with an isometry (rotation + translation) whereas a displacement vector can only be transformed with a rotation (no translation occurs).

To summarize, IMHO it is very valuable to represent units in linalg vectors and matrices, but this needs a unified treatment to also support non-uniform units in vectors and matrices and is best done by an additional layer on top of a LA library that has a user-interface which uses units but internally uses plain scalar vectors and matrices from any linalg library.

This also makes the LA core code easier on the compilers, a library like e.g. Eigen already contains lots of templates.

[kwikius]

Here FWIW is an example of a matrix multiply with physical quantities in my library

https://github.com/kwikius/quan-trunk/blob/master/quan_matters/examples/fusion/kalman1.cpp
(The matrix is essentially a tuple and, being a tuple, the compiler must precompute the type of the resulting matrix :
https://github.com/kwikius/quan-trunk/blob/master/quan/fun/make_matrix_mux_result.hpp#L140

I have done multiplication on 4,4 x 4,4 matrices and have tried larger matrices but compile time got very long and large amounts of memory where used by the compiler as the matrices got bigger

I also experimented with a "static value" which was designed as a matrix element to optimise out operations on constants by turning them into different types
https://github.com/kwikius/quan-trunk/tree/master/quan/fusion/static_value

An example optimisation is static_value<T1,0> * runtime_x -> static_value<decltype(T1{}*runtime_x),0> which is a nop at runtime and will be computed in the matrix_mux_result metafunction above.

Also compiletime /constexpr operations on such entities e.g inner_product
https://github.com/kwikius/quan-trunk/blob/master/quan_matters/test/fusion/inner_product.cpp

I found that compilation was too slow for most real uses ( may be good for rotation matrices etc), but it was fun getting it working

[kwikius]

Added a somewhat more complicated example with vectors
https://github.com/kwikius/units/blob/andy_master/example/trilateration.cpp

This is just a translation of my Trilateration example to mpusz/units
and uses some glue to get mpusz/units working with quan types

requires to include my quan library ( headers only required) to run
Anyway shows a use for unit aware 3d points vectors etc

example output
A = sphere(centre = [0 km, 0 km, 0 km], radius = 8 km)
B = sphere(centre = [10 km, 0 km, 0 km], radius = 5 km)
C = sphere(centre = [7 km, 7 km, 0 km], radius = 7 km)
intersection point = [6.95 km, 1.12143 km, 3.79999 km]

[jml1795]

Was taking a look through both the proposal and some of the discussion. I really like the idea of standard support for a units library and have tried some of the other referenced libraries in both toy and production code in the past.

Regarding LA support for units, one issue could be matrices and vectors that are inherently of mixed dimension. Something like a covariance matrix where you have a position x position block, velocity x velocity block, and pos x vel blocks likely end up causing issues. Not sure there is a work around, but worth giving it a thought.

[hatcat]

The linear algebra proposal, https://wg21.link/P1385, allows for customisation of all operators so you can provide your own algorithms. When you declare your particular vector or matrix type, the operator traits object is part of the spelling.

[mpusz]

Last week in Prague we made Untis library to work with P1385 :-) There are some changes still needed to be done but soon I will push the LA integration and some examples.

Regarding the question about storing different types in one vector/matrix, I am not aware of any LA library that does this (but it does not mean it is a bad idea).