Boost logo

Boost :

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at