Re: [boost] Preview 2 of a template Geometry Library

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-25 16:56:21

Max,

Thanks for your comments.

Max Motovilov wrote:
> (snip)( Nothing prevents me from collaborating on an existing 
> open source project though :)
>   
You're welcome!
> (snip)
> - I very much like the traits-based approach to determining the type of 
> calculation results. However a good extensible facility for deriving the 
> result type from argument types appears to be generally useful and not 
> at all specific to geometry. Unless there is one already in Boost (I am 
> not aware of it and quick check of the docs didn't help), perhaps it may 
> be introduced as a separate library?
>   
I think you refer to the "select_type_traits". That might indeed be a 
separate library. I glanced through the promotion library, which is in 
the 1.35 version. That covers a part but it is not exactly the way it is 
used here.

> - While generalized point types (2D vs. 3D and XY vs. lat/lon) are OK, 
> it is often extremely useful in graphics code to make your objects fit 
> the underlying representation of an externally defined structure (such 
> as POINT type in Win32) -- for example by publicly or privately 
> inheriting from it. This lets you use e.g. vectors of points as 
> arguments for system APIs. Can be done by adding an extra template 
> argument (with a default) to point<> and moving most of the 
> implementation details into a traits class.
>   
Sounds good. It is designed that those constructs should be possible. 
See also the comment of Bruno Lalande on this.
> - There is a box type but not a (1D) range type (I don't think you allow 
> 1D points, or do you?). It is often convenient to define operations on 
> bounding rectangles in terms of ranges. The comment about making point 
> types compatible with externally defined structure applies to boxes too.
>   
The generic point type might be 1D, but I didn't provide any algorithms 
or strategies for it. The box uses the point as a template parameter, so 
a 1D point could be used as template argument to create indeed a range 
type. So I think that will work.
For the externally defined structure, in most cases called "rectangle", 
it is probably more difficult. The code refers to min() and max() and 
that should then be resolved somehow.
> - I didn't find any facilites for linear transformations in your list. 
> Am I not looking in the right place or they aren't there? If the latter, 
>   it is probably the biggest omission. Or do you think this need is best 
> served with uBLAS? I have no idea if this can be done using uBLAS in 
> both efficient and convenient way so would like to hear everyone's 
> thoughts. I am very much used to writing things like:
>
> pt = shift( dst_offs ) * rotate( angle ) * shift( -src_offs ) * pt;
>
> or when it is a repeated operation:
>
> transform2D xf = shift(dst_offs) * rotate(angle) * shift(-src_offs);
> .......
> pt = xf * pt;
>
> or maybe even
>
> for_each( pts.begin(), pts.end(), _1 = xf * _1 ); // using lambda
>   
Linear transformations are intentionally left out because they are 
already there, in uBLAS indeed, didn't want to write vector/matrix 
calculations again. A sample could be useful to show this.
> - In 2D geometry, very many computations can be most efficiently 
> expressed in terms of dot product and cross product, so it wouldn't hurt 
> to have these operations implemented as part of the library. It probably 
> makes sense (I haven't done that before) to have a type for offset 
> vectors in geometrical sense separate from points: vec = pt - pt; pt = 
> pt + vec; et. al. The difference is that the offset part of a linear 
> transformation should apply to point but not to vector. Again, is this 
> something best done with uBLAS?
>   
Yes, in fact those products are already used. Because they're so simple 
I didn't replace them yet by uBlas. But it is a good idea, they can 
probably be replaced without any problem. I'm also curious to the 
opinions of the list about this.

Barend