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

Subject: Re: [geometry] translation and rotation proposal
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-03 22:57:59

Hi Barend,

Barend Gehrels wrote:
>>
>> 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).
>

You're talking about the transform strategies which internally are using 
ublas to apply some transformation. It's all that is implemented in 
Boost.Geometry regarding transformations. Right?

Currently the user must initialize those strategies either with elements 
of transformation matrix or coordinates of translation vector, etc. 
There is no simple way to e.g. find the rotation between points 
(normalized vectors). To do it the user would be forced to implement it 
by himself e.g. by using some linear algebra library, convert points to 
vectors, then calculate the rotation. To use it he would be forced to 
pass elements of the matrix to the strategy. Of course assuming that 
he's storing the transformation as matrix, otherwise he'd be forced to 
convert it.

I thought that, like in the case of Geometries, we could allow using 
user-defined representations of transformations. Then, users wouldn't be 
forced to convert vectors to points or create strategies from their 
matrices. If someone wanted to use e.g. QVM he'd just adapt matrices to 
our Matrix concept and would be able to rotate geometries without any 
conversions.

> 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.

Of course we shouldn't change the existing interface. This would brake 
backward compatibility. I'm thinking about adding features.

The interface is ok. I'm missing concepts and strategies using those 
concepts, that's all.

As you've pointed out those algorithms are well known. I'm thinking 
about providing the minimal set of algorithms needed for work with 
transformations - creating from geometries and applying to geometries. 
The rest should be done by some linear algebra library. And with 
concepts we'd be able to adapt any library.

However algorithms calculating the rotations and translation from points 
aren't probably necessary. convert() converting Points to Vectors would 
be enough. Or one could adapt his vector to Point concept.

>>
>> 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)?

It's almost the same. The main difference is that the result is a Vector 
which can be used to calculate something using some linear algebra 
library without the conversion of the Point to the Vector. Again, 
instead of this, one could adapt his vector to Point concept. This is 
IMO not very elegant, btw like subtracting one point from another.

>> - 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).
>

rotation() calculates the rotation representation from 2 vectors, could 
also work for points. This rotation is along the shortest arc between 
normalized vectors. For now it calculates 2x2 rotation matrix for 2D, 
3x3 rotation matrix or quaternion for 3D.

transform_geometrically() works basically like geometry::transform() 
with some transformer. It applies the transformation to Points. 
Therefore this function should be removed after the implementation of 
better interface - probably some additional strategies.

convert() converts between different rotation representations. For now 
it only converts between 3D rotation matrix and quaternion. It should 
probably convert also between rotations and transformation matrix. If 
there were additional rotation Concepts, like AxisAngle it should 
convert from it too.

>>
>> 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?

E.g. in image processing or robotics there is sometimes necessary to 
check how one set of points is placed in relation to the other one. What 
is the transformation (position and orientation, or pose) of a set of 
points in relation to some other, base set of points. ICP is an 
iterative algorithm which calculates it. Both sets of points musn't be 
exactly the same. The algorithm returns some approximation, closest best 
bet.

>> 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...
>

Sorry if I've messed up with extensions too much. I thought that this is 
the purpose of extensions, which is the place for some experimental 
features which can be dropped easily. I'll be more careful in the future.

Yes, all features are experimental, they may be removed. I've 
implemented them as an example of what I'm talking about in the emails. 
The ball is no longer needed. I'd hardly say that the rest exists 
though. However some of those features aren't needed. The minimal set 
would probably include only Concepts and strategies for translate().

> 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?

Everything is above. I have some doubts about the Concepts and 
interface, but this maybe later.

Regards,
Adam