Hi Adam,



2013/5/29 Barend Gehrels <barend@xs4all.nl>
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