Geometry Boost List: Re: [geometry] translation and rotation proposal

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

Hi,

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

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

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

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

Regards,
Adam