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

Subject: Re: [geometry] translation and rotation proposal
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2013-06-17 12:10:50

Hi,

So for sure we need a few additional concepts, i.e. Vector, Matrix,
> Quaternion.
>
> So then quaternion_type<point> and matrix_type<point>? Would this always
> return square matrix?
>

I don't see why we should provide concepts for quaternions and rotation
matrices right now. Tell me if I misunderstood but I thought the point of
the conversation has basically been to say that rotations and translations
are just yet another kind of transform strategies. So I thought the plan
was to develop new strategy classed to be passed to transform(),
implemented in terms of whatever mathematical tool you want to use.
"quaternion_rotation", "euler_rotation", "matrix_rotation" would be the
names of such strategies. Am I misunderstanding?

>   we could just put other concepts aside and implement some nice
> transformation strategies for bg::transform().
>

If by this you mean what I'm describing above then yes, that would be my
approach.

> Btw, should the strategy always have input geometries as template
> parameters? If not, calling bg::transform() could be simplified, e.g.:
>

I did some work recently on the distance strategies to have them take the
input geometries template parameters at function level (in their apply())
rather than class level. Not committed yet, I have to find the time for
that. But I guess the same idea would apply for other strategies. Basically
we need to free them from their class-level geometry template parameters in
order to make then more flexible and easy to use.

> bg::transform(poly1, poly2, bg::strategy::make_**translation(v_or_p));
>

Yep, that's exactly the goal of my change (for distance strategies - did
nothing on transform strategies so far - the distance strategy change was
already a huge work involving hours of work).

Regards
Bruno