-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Noah Stein Sent: Tuesday, March 25, 2008 11:17 PM
I am extremely interested in a boost affine geometry library, but given the history on this mailing list I suspect the best approach might
to
start with less rather than more.
Absolutely agree; some of my suggestions are definitely well out
be there.
The reason I am airing them up here is (a) to get thoughts on the subject from interested people which might help me implement some of it and (b) see if I might be able to work the prospective implementations into an open-source library that may perhaps be accepted into Boost. I've grown rather tired of re-writing the same libraries (granted, with improvements) over and over for each new project :)
I've written vector, point, and matrix classes many, many times. I'm in the middle of writing another one at the moment to try out proto. [John Femiani]
I definitely agree that expression templates will be a great benefit to a point library. Basically for me to be happy I need: 1) Documentation and code which follows the patterns in Boost.Concept, explicitly providing concepts that I can check in code and also providing archetypes and one or two reasonable models (models are less important to me). 2) A coordinates concept, which defines all of the typical operators much like a std::valarray, but is fixed-sized like a Fusion sequence. This generalizes the ideas of an affine point and vector, and it is really what many people on this list seem to mean by a "point". I am not sure whether points should be homogeneous vs. heterogeneous in terms of there element types, or whether run-time indexing is important enough to be handled by a separate concept in addition compile-time indexing. 3) A point concept, with an archetype, and at least a 2d and 3d model. * The point concept should be coordinate-free; The coordinates concept Should be separate. Affine transforms therefore should be Treated like function objects rather than c++ operators. Therefore, you say scale(s)(point) rather than p *= s, unless your point also satisfies CoordinateConcept. 4) A vector concept, with an archetype, and at least a 2d and 3d model. 5) A concept for an affine transform, and models for the basic ones: translate, rotate, and scale. A transform should be applicable to any another transform as well as to a point or a vector. The result of a transform should be impl. defined, so it may or may not be an expression type (ala proto?). The archetype needs to take this into account. 6) Conversion functions, make_vector, make_point, and make_coordinates that make adaptors or something so that one type can be forced to another. The adaptors should have zero runtime overhead. I have been saying "affine" geometry because I think that other geometries (i.e. projective), while very useful, should be handled after the affine case is nailed down. There are some behavioral aspects of points & vectors that may need runtime tests. The geometry library should have well documented invariants that can be checked for any geometric type. Anything beyond points, vectors, coordinates, and transforms is probably overkill in my opinion (so far), I would really just like this one thing nailed down. -- John C. Femiani