Re: [boost] interest on a geometry library

From: Geoffrey Irving (irving_at_[hidden])
Date: 2006-03-24 12:56:22

On Fri, Mar 24, 2006 at 03:28:20PM -0000, Andy Little wrote:
> 
> > 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.
> 
> Is there any reason to build 3d on top of 2d ?.
> Is this from an academic point of view where mathematicians enjoy generalising
> geometry to  N dimensions?
> My own use seems to consist mainly in 3 dimensions, with some 2 dimensions.
> Generalisation to N dimensions seems to have little practical use
> ... or does it ?

I was referring to building more complicated code dimension by dimension which
uses the vector classes.  For example, if you have 3D algorithms that want to
project onto a lower dimensional space for some reason, and you want to test them
in 2D, you need 1D versions of everything.  This kind of flexibility has saved
us vast amounts of implementation and debugging time.

> > 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();
> >    }
> 
> Or even :
> 
> template <typename TL, typename TR>
> zero<BOOST_TYPEOF_TPL(TL() * TR) >
> operator*(zero<TL> a, TR b)
> {
>        return zero<BOOST_TYPEOF_TPL(Tl() * TR) >();
> }
> 
> [...]

Leaving the template argument off zero was intentional.  As long as you have
homogenous units (i.e., pretty much everything but Celsius), zero can be
untyped.  If you have nonhomogenous units, you should not be sticking them
in a matrix.

> > 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 matrices are maximum of 4 x4 I would think that compilation times would be
> acceptable for numeric value anyway. It also happens to fit in somewhat with my
> own slightly whacky
> matrices which are more like tuples because not all the elements are the same
> type. Some are numeric , some are quantities while some are the reciprocal of a
> quantity. For instance in my geometry library a 2D  RC matrix decribing a
> rotation of 45 degrees about a point 1mm from the
> x origin and 1 mm from the y origin looks like so:
> 
> |   0.707107,  0.707107     , 0 m-1 * 1e3 |
> |  -0.707107,  0.707107     , 0 m-1 * 1e3 |
> |   1 mm       , -0.414214 mm,     1             |

That's another good example.

> The units relate to the various transforms. The angular and scaling elements are
> numeric, while the translation elements have distance units of millimeters and
> the perspective elements have units of per millimeter ( simply the reciprocal of
> millimeters represented as m-1 * 1 e3 here). The units provide a useful
> reference over simply using numeric types.
> 
> The per millimeter elements and scaling could do with being optimised away in
> this case though.  Maybe I could add an extra integer parameter
> with a 32 bit int, with two elements for each bit (for a 4 x4 matrix) 
> representing whether that
> element was a compile time constant (One or Zero or a runtime variable. I would
> guess that you could then use boost::mpl::if_<Maskint && MyBits == 0,zero,
> T>::type  for each element to get this behaviour. In math operations this would 
> also carry through to the result type of course as in the simple example above.
> 
> >> 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).
> 
> What is a frame?

I'm using frame as a synonym for an element of SE(3), the position/orientation
combo mentioned above.

Geoffrey