From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-25 16:56:21
Thanks for your comments.
Max Motovilov wrote:
> (snip)( Nothing prevents me from collaborating on an existing
> open source project though :)
> - 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
> - 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk