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

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-03-26 02:56:56

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> 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
be
> to
> > > start with less rather than more.
> >
> > Absolutely agree; some of my suggestions are definitely well out
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