Subject: Re: [boost] Formal review for QVM
From: Rajaditya Mukherjee (rajaditya.mukherjee_at_[hidden])
Date: 2015-12-13 18:23:50
Oswin Krause wrote:
>> We encourage your participation in this review. At a minimum, kindly
>>> - 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.
> 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.
Also from reading the clarifications to my review, I understand that most
of my concerns were alleviated and *hence I would recommend that this
library be added to boost. *
> I'm guessing that if Emil wanted to implement some advanced algorithms
> from some specific domain he'd be forced to redesign parts of the library,
> e.g. represent data in a different way, provide specialized containers,
> etc. It's also possible that this approach would be incompatible with some
> other one suitable for a different domain. And this is the reason why QVM
> is implemented on a high level of abstraction. So it may be used as a link
> between various domain-specific libraries. Is that correct?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk