Re: [boost] Formal review for QVM

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
>>
>>> state:
>>> - 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.
>>
>
> Thanks!
>
> 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?
>
> Adam
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>