Re: [boost] interest on a geometry library

From: Geoffrey Irving (irving_at_[hidden])
Date: 2006-03-22 16:44:46

On Wed, Mar 22, 2006 at 09:52:02PM +0100, Janek Kozicki wrote:

> > It strikes me that perhaps more detailed discussion
> > about  the goals and rationale of such a library is needed too.
> 
> yes, certainly. At first we should decide what entities should appear,
> how to name them, and how to sort them into namespaces, to begin with,
> that's my library:
> 
> - vector2    +
> - vector3    +
> - vector4    +
> - matrix2    +
> - matrix3    +
> - matrix4    +
> - quaternion +
> - se3        +
> 
> Other readers of this list are welcome to add more components and "vote"
> by placing '+' next to it. Of course class names are subject to another
> discussion :)

As far as naming goes (other than my slight preference for vector_?d),
frame3 is seems more consistent with the others (unless you want to call
the others r3, gl3, h, etc.).

I would also suggest adding these:

- vector1    +
- matrix1    +
- diagonal_matrix2 +
- diagonal_matrix3 +
- symmetric_matrix2 +
- symmetric_matrix3 +
- upper_triangular_matrix2 +
- upper_triangular_matrix3 +

One dimensional versions are very convenient for debugging and hierarchical
template code (building 3d on top of 2d on top of ...).  Depending on the
rest of the design scalars might be sufficient, though.

Specialized versions of matrices are less commonly needed but extremely
convenient when you do.  They also add a significant benefit in terms of 
self-documentation and automatic type checking.

If compilation time weren't an issue, it would be quite interesting to build all
of these out of a general sparsity small matrix class.  With enough trust in the
compiler, that could be done by making a zero type and overloading all the
arithmetic operators to know about zero, e.g.,

    zero operator*(zero a, float b)
    {
        return zero();
    }

It would be great to hear if anyone with more metaprogramming experience has any
comments of the feasibility/costs of that approach.  I imagine that compilation
times alone make this impractical for now, not to mention the complications for
anyone trying to read the code.

> If you are wondering, se3 is a position/orientation combo - small class
> which contains only vector3 and a quaternion. It is used to fully
> describe a placement of an object in 3d space. I'm still not sure whether
> getting rid of it would make things simpler or not.

I would strongly vote for frames.  Otherwise people familiar with homogenous
coordinates will fall back to using matrix4 and lose on elegance, speed,
memory, and robustness (speed only sometimes).

Geoffrey