Geometry Boost List: Re: [geometry] translation and rotation proposal

Subject: Re: [geometry] translation and rotation proposal
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-06-03 17:11:26

Hi Adam,

>
> 2013/5/29 Barend Gehrels <barend_at_[hidden] <mailto:barend_at_[hidden]>>
>
>     On 29-5-2013 3:23, Andrew Hundt wrote:
>>     I recommend taking a look at how eigen does things for ideas
>>     before any major design decisions, and consider the possibility
>>     of directly integrating with ublas as well once you start getting
>>     into real matrix operations.
>
>     The currently implemented matrix operations (transform strategies)
>     are using ublas.
>
>     <snip>
>
>     Please also refer to Boost QVM:
>     http://www.revergestudios.com/boost-qvm/
>
>     This is not (yet) a boost library, and already for long in the
>     review queue, but it is worth to visit. I hope that it will become
>     part of Boost and we could then use that library (instead of
>     current Ublas usage).
>
>
> Yes, I know this library. I thought about providing Concepts, i.e. 
> Vector, Rotations representations, Translation, etc. One would be able 
> to adapt vector and matrix classes he'd like to use for linear algebra 
> - uBlas, QVM or other.

That sounds, basically, as a good idea. So they are indeed already 20 
new headerfiles in the svn source tree, as you state below. OK, great, 
have you already implemented the concept for one case, e.g. ublas? Such 
that we can test the things and change the current matrices with their 
implementation (they currently use ublas, at least for inversion).

> Also, I thought about providing algorithms needed for creation of 
> those, e.g. translation between points, rotation between two 
> points/vectors, appending rotations and translations to create 
> transformation, conversion between different representations, etc. And 
> of course, implementing a function applying those transformations to 
> all geometries.

You know all these algorithms already exist for years? I think you know, 
but you bring this as new to the list, so what is the rationale to 
change the current implementations, instead of extending 
implementations? Do you propose to be backwards compatible? What was 
exactly the thing(s) missing to propose and implement all these new 
things? Is the interface wrong, or the implementation, or just concepts 
that you missed?

I realize (and assume) the current functionality is not widely used, so 
yes many things might miss. But these algorithms (e.g. transform) 
already exist for years, we cannot change it without reason.

>
> For now I've implemented:
> - Vector, RotationMatrix and RotationQuaternion concepts,
> - translation() calculating Vector between two cartesian points,

What is the difference between this and "subtract_point" (which was in 
arithmetic)?

> - rotation() calculating Rotation representation between Vectors,
> - transform_geometrically() applying transformations to Vectors and 
> Points - temporary,
> - convert() converting between rotations representations.

Can you specify the last three items? I just don't understand it. 
calculating rotation between vectors, do you mean that you have one 
origin, two vectors (probably unit vectors), and calculate the 
transformation matrix from these? Actually I don't understand the exact 
meaning of all these things you specify. Without looking at the source 
(I did not do that yet).

>
> Implemented but probably not needed or should be changed:
> - assign_zero() for Vectors,
> - assign_identity() for Rotations (new function),
> - clear() - experimentally, setting Vectors to 0 and Rotations to 1 - 
> create empty
> - reverse() - experimentally, negating Vectors and inverting Rotations 
> - create the opposite
>
> Missing:
> - TransformationMatrix concept,
> - function connecting transformations together e.g. 
> append(transformation, next);
> - use of geometry::transform()
> - other coordinate systems
>
> The future:
> - algorithm calculating  transformation of a set of points, e.g. ICP.

Can you specify this more?

>
> Questionable:
> - RotationMatrix and TransformationMatrix could be one concept - Matrix,
> - then RotationQuaternion could be named Quaternion,
> - dimension<RotationQuaternion> is 3 even if it has 4 components 
> because it represents rotation in 3D,
> - dimension<TransformationMatrix> would probably be 2 for 2d even if 
> it were 3xe, for 3d even if it were 4x4,
> - transform_geometrically() should probably be replaced by 
> geometry::transform(),
> - clear() and reverse() are experimental and should probably be 
> changed by something else or removed,
> - assign_identity() would be not needed if there is some kind of 
> clear()/init(), and is probably not needed at all.
>

Great work! However, up to now is it good to consider them all as 
experimental? I really appreciate you're hard working on this, but 
within a week we have to cope with 20 new headerfiles, with 
implementations of things which were already there, though in a 
different (and maybe not perfect) form, without proper discussions 
before... We have to be able to keep the overview, no? And besides this 
there are the new things and new headerfiles for ball (which also 
already existed) too...

I realize you mailed recently about this, 27/5, but one or two days 
later you mailed that it was sent too hastily. So it was mostly ignored. 
Or do we still have to re-read these mails before understanding the 
things above?

Anyway, thanks for your initiatives and hard work, of course, and I hope 
we will be able to integrate the old and new implementations, the 
concepts idea (at least) sounds good to me.

Regards, Barend