Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Rajaditya Mukherjee (rajaditya.mukherjee_at_[hidden])
Date: 2015-12-13 01:15:32

*Please find attached my review of QVM library.*

*Whether you believe the library should be accepted into Boost*
*Conditionally Accepted into Boost*
*  * Conditions for acceptance*
1. The author should provide out of box versions of 2,3,4 dimensions vector
matrix quaternion classes which can be readily imported by the user and
used (without messing around with traits and such).
2. An effort should be made to make the APIs more compatible with current
libraries such as Eigen and Armadillo. For instance take the norm
operations : Both Eigen and Armadillo uses the norm()keyword for the norm
and normSquared() (only in Eigen). However QVM uses mag and mag2 which is
pretty non-intuitive. I would encourage Emil to explore this aspect so that
the learning curve for the new library is less.
3. Compatibility with GLSL pipeline (like glm currently provides ) will be
a big plus since it is the target demographic for this library.

That said, this is a good library which emulates the functionality like
*GLM* (http://glm.g-truc.net/0.9.1/api/index.html) with an array of
features that both new users (not so much) and advanced users will find
useful. However the target demographics for this library will be mostly
graphics people. But I still believe this is a good thing for boost to have
and it will nicely complement the existing linear algebra framework
provided by uBLAS.

*Your name*
Rajaditya Mukherjee

*Your knowledge of the problem domain.*
I am a Phd student in Computer Graphics and I have been working with
Matrices and Vectors for my research for the past 4 years. I am also aware
of Eigen, uBLAS, armadillo, openCV and CGAL's matrix Vector implementations
since I have used all of them in my research code.

*You are strongly encouraged to also provide additional information:*
- *What is your evaluation of the library's:*
 * * Design*
I havent gone through the entire set of APIs but I have selectively ran the
test files for the features of interest to me (such as Swizzling and
Quaternions). However I have certain comments about the nomenclature of the
principle APIs (which I have gone over in the Conditions for acceptance
section). Another issue I have is with the matrix-matrix view operation.
Currently it supports only single row and column deletion. I would like it
if we can arbitrarily select a starting index and a certain number of rows
and columns (imagine the view proxy operations in uBlas if you will) This
limits the usefulness to a certain degree.
 * * Implementation*
The implementation looks robust enough to support its claimed compatibility
with generic types.
*  * Documentation*
 I have some issues with the nomenclature of APIs. I believe this is one of
the conditions of my acceptance.
 ** Tests*
The test battery is pretty comprehensive. However some of them require
modifications to run in the new system because they use
boost::test_tools::check_is_close which is depreciated in the current
version as per this link (
http://lists.boost.org/boost-users/2015/09/85042.php). I would request Emil
to update them as per the link so it runs without modification on newer
boost systems.
  ** Usefulness*
This will be useful for Graphics Applications to compute the various
rendering matrices (MVP) that are needed in the graphics pipeline and other
allied geometric transforms. *This is a very special purpose library. Users
interested in deeper linear algebra applications will find uBLAS more to
their liking. *
*- Did you attempt to use the library? If so:*
  ** Which compiler(s)*
MSVC 2013
  ** What was the experience? Any problems?*
There are certain trivial issues I encountered with MSVC. Emil resolved
them pretty fast in the mailing list but right now, this library is not
very MSVC friendly. Also, the test battery needs to be upgraded for newer
boosts. (I had to manually change some header files and a couple of lines
here and there).
On a non-implementation note, there is a certain learning curve with this
library. For instance the library absolutely needs the default constructor
for certain operations (normalized in my case couldn't run without a
default constructor, I will be happy to discuss the exact testing scenario
that brought this comment as a followup).  This should be mentioned clearly
in the requirement for the generic types. (Maybe this is something Emil can
clear up in the final version)

*- How much effort did you put into your evaluation of the review?*
7 hours sporadically (not in a single sitting)

*Rajaditya Mukherjee*
*​4th Year Graduate Student*
Dept. of Computer Science and Engineering
The Ohio State University
Columbus, Ohio
Tel :- [phone]
email :- rajaditya.mukherjee_at_[hidden] <mukherjee.62_at_[hidden]>,
raj_at_[hidden] <mukherjr_at_[hidden]>

*Rajaditya Mukherjee *
*3rd Year Graduate Student*
Dept. of Computer Science and Engineering
The Ohio State University
Columbus, Ohio
Tel :- [phone]
email :- rajaditya.mukherjee_at_[hidden] <mukherjee.62_at_[hidden]>,
raj_at_[hidden] <mukherjr_at_[hidden]>

On Thu, Dec 10, 2015 at 4:06 PM, Emil Dotchevski <emildotchevski_at_[hidden]>
wrote:

> Oswin, thank you for the thoughtful evaluation. I'll respond to a few of
> your points below.
>
> On Thu, Dec 10, 2015 at 9:52 AM, Oswin Krause <
> Oswin.Krause_at_[hidden]> wrote:
>
> > qvm has to be seen in this context as the 15th standard designed to unify
> > the 14 other standards that are out there( https://xkcd.com/927/ ). I
> > think it does a good job at it as it provides a reasonable abstraction
> > layer and a set of operations which then can be used without taking the
> > types of the arguments into account, so that points from the one library
> > can be taken and easily used together with the points of another library.
> >
>
> I appreciate this comment, it's exactly what motivated the design of QVM.
> However, there is another side effect: because in QVM the operations are
> decoupled from the types, it becomes practical to emit many different types
> from various operations. This enables the use of what I call view proxies,
> e.g. rotx_m takes an angle as float const & and "reinterprets" it as a
> rotation matrix without any temps.
>
>
> >   * Design
> >>
> > The design makes sense. However for many use cases the current bindings
> > are too complicated and for the problem of interoperability of point
> types,
> > the issue of order has to be addressed, e.g. if one library takes points
> as
> > ARGB while the other provides them as RGBA, assigning points between the
> > two libraries should automatically do the right thing and not assigning
> the
> > R part of the one point to the A part of the other. Bindings should make
> > this explicit as swizzling is always a source of confusion and the
> library
> > should make it as simple as possible to make this automatic.
> >
>
> I'm confused, the order is explicit in the bindings, you could store vector
> elements as YXWZ if you want, or even not store all of them, e.g. you could
> store X, Y and Z and bind W as 1 or 0.
>
>
> > My issue with the library is, that it provides the bindings for very
> basic
> > operations, but no advanced functionality that makes it superior over the
> > three other point definitions that some projects might already have. Most
> > importantly, i miss functionality regarding sets of points which are
> stored
> > continuously in memory e.g. a std::vector<My3DVector>. We can often gain
> a
> > bit by using the fact that this is equivalent to some T[N*3] array and
> > optimize operations for this case.
>
>
> This is a good point but I consider this outside of the scope of generic
> libraries like QVM because such gains are too tightly coupled with the
> physical layout of your data. An interface that lets you multiply 20000
> matrices with maximum efficiency won't be nearly as friendly as QVM; its
> matrix and vector types will have all kinds of physical restrictions,
> alignment requirements, etc. which may not be reasonable in contexts that
> need to deal with only a few objects.
>
> Yet QVM lets you bind such uber-fast (and in, my experience, often
> platform-specific) types and use them together with more civilized,
> higher-level types.
>
>
> > further, i think it misses some more advanced math used in actual
> > simulations, e.g. defining rotations with time steps based on angular
> > velocities, for example as provided by screw theory.
> >
>
> This might make sense to add to QVM, I can't tell because that's outside of
> my expertise.
>
>
> > - boost::math has a quaternion class already. Could they be used as
> > default? Do we need two competing concepts of quaternions?
> >
>
> The question do we want another quaternion, vector or matrix type is a good
> one, and the answer is that what what we want doesn't matter: as a matter
> of fact there are a ton of quaternion, vector and matrix types already.
> Actually QVM lets you define or emit 20 more tons of such types, I consider
> that a good thing. :)
>
>
> > - what about user defined value types, e.g. high precision math?
> >
>
> This is supported, see
> http://zajo.github.io/boost-qvm/scalar_requirements.html.
>
>
> > - what about boost.geometry? Does qvm come with the necessary type
> traits?
> > If a user has its own point type and wants to use it together with qvm
> and
> > boost.geometry, does he have to provide type traits for both libraries?
> >
>
> There is some overlap between Geometry and QVM but it is less clear if they
> can be unified or if that's a good idea.
>
> Thanks!
> Emil
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>