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

From: Max Motovilov (max_at_[hidden])
Date: 2008-03-25 14:30:58

This is a topic I find extremely interesting since by the will of fate I 
  keep coming back to it in the course of my everyday work. In fact, I 
have implemented (fully or in part) a similar set of library facilities 
3 times in a row... and I can't very well opensource any of the three 
implementations :( Nothing prevents me from collaborating on an existing 
open source project though :)

I have only glanced briefly through the documentation so my comments may 
be based on an incomplete picture; I apologize in advance if that's the 
case. Nevertheless I am going to respond right away just so you know 
you're not alone ;). I'll also try to spend more time reviewing your 
library later today.

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

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

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

- 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

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

Ok, really need to go back to work. I'll probably have more to say on 
this later.

...Max...