Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2015-12-14 10:17:17

Hi all,

On 2015-12-14 00:23, Rajaditya Mukherjee wrote:
> Oswin Krause wrote:
>> 
>> Do you vote for conditional acceptance under the condition that in
>> addition to basic operations also more advanced algorithms should be
>> implemented in the future? Or that the library shouldn't be accepted 
>> at
>> this point?
>> Emil are you willing to extend the scope of the library?
>> 
> 
> ​Hi Adam, I believe that since this library specifically targets 
> operations
> in geometric spaces in 2/3/4d, advanced operations are out of the scope 
> for
> this library. It is my understanding (and I may be very wrong here 
> since
> Oswin is a much more senior member of this community than me) that QVM
> supports all the operations that I would currently expect from it - it 
> is
> not a substitute for uBLAS since uBLAS is a complete linear algbera 
> library
> with solvers and advanced matrix functionalities. QVM caters to the
> graphics community with support for operations like swizzling which I 
> often
> use when I am working with GLSL shaders(the client ops.). Just like I 
> use
> glm and eigen in my current projects, I can envision people using QVM 
> and
> uBLAS in a similar fashion with one complementing the other.

There are many specialized use-cases for 2,3 and 4D geometry which are 
not in the scope of the BLAS packages - but important for the graphics 
people and similar fields. I am not talking about big algorithms for 
every use-case like a general SVD. But the library should offer more 
than the bare minimum of operations required for 3D Geometry. It does 
not touch most of basic operations for points (e.g. clamping) or 
projective geometry. Similarly, it misses most stuff needed for 
kinematics - i can define a rotation, but can not easily figure out 
which force it applies(the FAQ section explicitly mentions 
"simulations", therefore I assumed some basic physics to be relevant). 
Of course, one can construct most of this using the basic operations in 
the library, but it would be nice if it had it in the first place, 
especially as it requires some effort and enable_if magic to add new 
operations I am not sure whether a pure "glue-code" library is going to 
be successful as part of boost. I see the need for a library that can 
handle whatever is thrown at it, but this also requires that it offers a 
wide bandwidth of operations for many use-cases and/or an interface that 
is easy to extend. Regarding the latter: the documentation currently 
falls short on describing how to extend the library and therefore I 
conclude that this is not a goal.

>> Do you vote for conditional acceptance under the condition that in
>> addition to basic operations also more advanced algorithms should be
>> implemented in the future?

I am going to vote for conditional acceptance under the condition of a 
consensus on the scope of the library(i.e. I am not going to stand in 
the way if the boost community sees it as sufficient if QVM is a pure 
glue between more powerful libraries). If the scope is intended to be 
broader than "glue code" I would like to hear about a roadmap for what 
is going to be added or how the library author envisions its 
development.

Otherwise the library looks pretty okay, aside of a few naming issues 
which I do not consider to be a problem as they are easy fixes (transp() 
and trans() are misleading, then there are many shorthands like deduce_s 
which are not very obvious to understand, the mag() issue raised earlier 
etc.).

Best,
Oswin