Hi,


Bruno, do you have an opinion about this?

I often think about it and basically always come to the same conclusion. Basically there are 2 categories of users around this and we need to satisfy them all:
- some people care a lot about vector/point distinction, and don't want subtract_point to return a point, they don't want to be able to add 2 points (makes no sense), etc... => we need to ensure that in the library
- some people don't care at all (I'm among them, with a mostly game-oriented background) - they use the "point" and "vector" words interchangeably => we need to keep the library as permissive as it currently is for them

So all in all, the library needs a way to define what is the vector type corresponding to a point type. Could be a vector_type<point_type> metafunction. Could also be called difference_type<point>, since in essence a vector is the difference between 2 points and "difference_type" sounds familiar to C++/STL users. People who don't care about the distinction want vector_type<point_type> to return point_type. People who care want it to return a different type (with possibly same underlying structure, but different from a type system standpoint). The metafunction would be called by arithmetic operations and things like that.

Regarding the model, we would of course be adding a model::vector type. Now the problem is which default to give it for vector_type<model::point>, i.e. which type of users we'd like to support by default - as there has to be one I suppose.

Does the approach make any sense?

Regards
Bruno

 





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


_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/geometry