Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-10 16:06:11

Oswin, thank you for the thoughtful evaluation. I'll respond to a few of
your points below.

On Thu, Dec 10, 2015 at 9:52 AM, Oswin Krause <
Oswin.Krause_at_[hidden]> wrote:

> 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.
>

I appreciate this comment, it's exactly what motivated the design of QVM.
However, there is another side effect: because in QVM the operations are
decoupled from the types, it becomes practical to emit many different types
from various operations. This enables the use of what I call view proxies,
e.g. rotx_m takes an angle as float const & and "reinterprets" it as a
rotation matrix without any temps.

>   * 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.
>

I'm confused, the order is explicit in the bindings, you could store vector
elements as YXWZ if you want, or even not store all of them, e.g. you could
store X, Y and Z and bind W as 1 or 0.

> 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.

This is a good point but I consider this outside of the scope of generic
libraries like QVM because such gains are too tightly coupled with the
physical layout of your data. An interface that lets you multiply 20000
matrices with maximum efficiency won't be nearly as friendly as QVM; its
matrix and vector types will have all kinds of physical restrictions,
alignment requirements, etc. which may not be reasonable in contexts that
need to deal with only a few objects.

Yet QVM lets you bind such uber-fast (and in, my experience, often
platform-specific) types and use them together with more civilized,
higher-level types.

> 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.
>

This might make sense to add to QVM, I can't tell because that's outside of
my expertise.

> - boost::math has a quaternion class already. Could they be used as
> default? Do we need two competing concepts of quaternions?
>

The question do we want another quaternion, vector or matrix type is a good
one, and the answer is that what what we want doesn't matter: as a matter
of fact there are a ton of quaternion, vector and matrix types already.
Actually QVM lets you define or emit 20 more tons of such types, I consider
that a good thing. :)

> - what about user defined value types, e.g. high precision math?
>

This is supported, see
http://zajo.github.io/boost-qvm/scalar_requirements.html.

> - 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?
>

There is some overlap between Geometry and QVM but it is less clear if they
can be unified or if that's a good idea.

Thanks!
Emil