Re: [Boost-users] [boost]Formal review for QVM

Subject: Re: [Boost-users] [boost]Formal review for QVM
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2015-12-10 12:52:47

Hi,

here my quick review based on the documentation. I will not partake in 
the current discussion of the swizzling syntax.

> We encourage your participation in this review. At a minimum, kindly
> state:
> - Whether you believe the library should be accepted into Boost
Not now, but at a later point surely.

>   * Conditions for acceptance
This is not because the library is not relevant or useful, or because of 
bad design, but because it misses important functionality in the current 
state that would give it impact in the current ecosystem. "If I already 
have to use two competing point libraries, why should I additionally 
introduce qvm?"
The scope must be broadened by including some advanced algorithms which 
make qvm useful in the ecosystem, also interoperability with already 
existing boost components must be established. Some of its functionality 
already exists in boost, which makes acceptance as a standalone library 
a bit odd. It could be worthwhile to merge qvm with another geometry 
related boost library to strengthen the links between the libraries.

> - Your knowledge of the problem domain.
I have got basic knowledge in robotics and graphic applications, some 
physical simulations

> 
> You are strongly encouraged to also provide additional information:
> - What is your evaluation of the library's:
>   * Usefulness
One has to see this library in the context of current program design in 
robotics. Typically we have some robotic application, for example an arm 
that has some software to move its joints in space.
On the other hand we have a physical simulation of the arm, the object 
it carries, forces that are applied to it, and often a graphical 
simulator showing the (simulated) position of the arm. These software 
pieces are developed by different groups which need a definition of a 
point or a matrix etc and somehow these parts have to be stitched 
together in an application so that they work.

qvm has to be seen in this context as the 15th standard designed to 
unify the 14 other standards that are out there( https://xkcd.com/927/ 
). I think it does a good job at it as it provides a reasonable 
abstraction layer and a set of operations which then can be used without 
taking the types of the arguments into account, so that points from the 
one library can be taken and easily used together with the points of 
another library.

>   * Design
The design makes sense. However for many use cases the current bindings 
are too complicated and for the problem of interoperability of point 
types, the issue of order has to be addressed, e.g. if one library takes 
points as ARGB while the other provides them as RGBA, assigning points 
between the two libraries should automatically do the right thing and 
not assigning the R part of the one point to the A part of the other. 
Bindings should make this explicit as swizzling is always a source of 
confusion and the library should make it as simple as possible to make 
this automatic.

In many cases, points are some POD type in one of the many conventions 
for which reinterpret_cast<T(&)[N]>(p) is a valid expression. The only 
thing that needs to be provided for such a type is the order of 
elements. Thus it would be really good if the library could provide, for 
these cases, a simple binding macro

BOOST_QVM_VECTOR_3D(MyType,T,XYZ) //MyType is equivalent to a T[3] with 
convention X-Y-Z in memory

My issue with the library is, that it provides the bindings for very 
basic operations, but no advanced functionality that makes it superior 
over the three other point definitions that some projects might already 
have. Most importantly, i miss functionality regarding sets of points 
which are stored continuously in memory e.g. a std::vector<My3DVector>. 
We can often gain a bit by using the fact that this is equivalent to 
some T[N*3] array and optimize operations for this case. Other 
operations that are used in these cases are also: transforming point 
sets between different formats, e.g. interleaving channels, removing 
channels(or creating a view that hides the channel)...

further, i think it misses some more advanced math used in actual 
simulations, e.g. defining rotations with time steps based on angular 
velocities, for example as provided by screw theory.

I am not sure of the following points regarding interoperability with 
existing boost parts:

- boost::math has a quaternion class already. Could they be used as 
default? Do we need two competing concepts of quaternions?
- what about user defined value types, e.g. high precision math?
- interoperability with boost.units? can i have a vector of positions, a 
vector of velocities and a scalar timestep and have the type magic 
working properly? (Is this relevant?)
- what about boost.geometry? Does qvm come with the necessary type 
traits? If a user has its own point type and wants to use it together 
with qvm and boost.geometry, does he have to provide type traits for 
both libraries?
- would it work with odeint? any troubles on this side to expect? Here, 
a proper timestep mechanic could really help!

Best,
Oswin