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-04 15:05:15

Hi Adam,

Thanks for your extensive clarifications.

On 4-6-2013 4:57, Adam Wulkiewicz wrote:
> 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?

Yes, and slightly related the arithmetic calculations to subtract/add 
points.

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

That is completely true.

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

Yes, that is a good idea. When we developed Boost.Geometry and prepared 
it for review, we thought and hoped QVM would follow soon. And then we 
could use that for all kind of vector and matrix calculations that we 
use sometimes internally, and that users could use for e.g. 
transformation. Therefore these things were postponed. But what often 
happens with postponed things... is that they are postponed for very long.

So yes, it is good to have a good solution, I agree.

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

OK, good that this is clear.

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

OK, this is more clear now. Yes, convert a point to a vector makes 
sense. I have at some places made a typedef to make it clear that a 
vector is meant and not a point, but it might be good to state this 
explicitly.

Bruno, do you have an opinion about this?

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

OK, I see and agree.

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

OK.

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

OK, so this was indeed not clear enough. The "extensions" are meant to 
be in development and at a certain phase promoted to the central part of 
Boost.Geometry. Up to now they (mostly) have more or less their 
definitive interface, though it might be changed if necessary.

But maybe we indeed can make a similar tree with "experimental" 
features. I think that is a good idea, to change thoughts as we did now. 
Because they were all in extensions I assumed this was meant to be 
developed further etc, it seemed quite complete, so good to hear it was 
more meant for discussion.

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

OK great, thanks again for your explanations, it is much more clear to me.

Regards, Barend