Boost logo

Geometry :

Subject: Re: [geometry] translation and rotation proposal
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-06 13:43:32


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

Are you telling that this experimental dir be in trunk or somewhere
alone e.g. in /svn/boost/branches?

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

As for the Concepts. Now there are:

Vector - n-dimensional

3d so dimension<> == 3 even if it has 4 components! This means that this:
get<dimension<...>::value>(rot_qua); // is ok!

2d for rotation in 2d (2x2 matrix), dimension<> == 2
3d for rotation in 3d (3x3 matrix), dimension<> == 3

Of course some Translation concept is missing. In this model we would
also have TranslationMatrix concept which would be:
2d for translation in 2d (even if it were 3x3 matrix), dimension<> == 2
3d for translation in 3d (even if it were 4x4 matrix), dimension<> == 3
So this would be possible:

get<dimension<...>::value, dimension<...>::value>(tran_mat); // compiles
// but
get<dimension<...>::value, dimension<...>::value>(rot_mat); // error!

This model's advantage is that we can distinguish between transforms by
checking tag and dimension. So we can implement convert() that exactly
knows to which Concept it converts. E.g. if we wanted to allow
converting 2d rotation matrix to 2d transformation matrix or to 3d
rotation matrix we'd exactly know what to do even if they were both 3x3

And we'd be able to handle easily 2d 2x3 or 3d 3x4 transformation matrix
(without scale) just by introducing additional concept.

The drawback is that the user should have different types defined for
each one of those Concepts! So probably any linear algebra library
couldn't be used directly.

We could of course think about some wrappers for each Concept, wrapping
user-defined Matrix type and providing conversion to wrapped Matrix.
Somewhere at the bottom we'd be forced to implement basic Matrix concept
which could be used by wrappers.

So we could just simplify things greatly. Handle transformations using
basic Vector, Matrix, Quaternion, etc. and let users worry about the
rest - e.g. conversions.

Those simple concepts have a weak point - dimension<>. It can't be
applied to Matrices and in the case of Quaternions it has no sense.
Well, we could use it but we'd be forced to handle only square matrices.
Or we could implement some different traits for those Concepts, or at
least for Matrix, e.g. indexed_dimension<Obj, I> (with this we could
probably even handle higher-rank tensors however I don't know if they'd
be usable in our case).


Geometry list run by mateusz at