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