
Geometry : 
Subject: Re: [geometry] translation and rotation proposal
From: Barend Gehrels (barend_at_[hidden])
Date: 20130603 17:11:26
Hi Adam,
>
> 2013/5/29 Barend Gehrels <barend_at_[hidden] <mailto:barend_at_[hidden]>>
>
> On 2952013 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/boostqvm/
>
> 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 reread 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
Geometry list run by mateusz at loskot.net