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