Re: [boost] interest on a geometry library

From: Andy Little (andy_at_[hidden])
Date: 2006-03-24 10:28:20

"Geoffrey Irving"  wrote
> Janek Kozicki 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 ?

> 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) >();
}

This would for instance allow use of  the types in my pqs library:
http://tinyurl.com/7m5l8

e.g

zero<pqs::mass::kg> mass;
BOOST_AUTO(force,  mass * pqs::acceleration::g);

This reminds me somewhat of expression templates too.

> 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             |

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?

regards
Andy Little