On 11/8/06, Jason Kraftcheck <kraftche@cae.wisc.edu> wrote:
Jason Hise wrote:
I did something very much like this a while back, which was submitted as a potential jumping off point for a boost geometry library. It is in the boost vault under Math - Geometry (http://tinyurl.com/ymjsoz), along with two other submissions. (Mine is geometryJH_01.zip).
I think that my design of the matrix class is a little better because a vector is defined as a Nx1 matrix, rather than the matrix being defined as an array of vectors. This avoids the need for special operators for vector-matrix multiplication, is closer to the underlying mathematical concept, and makes the equivalency of a vector and column matrix explicit.
I suppose this makes sense from an efficiency standpoint. I prefered the matrix as a vector of vectors because it made defining algorithms in terms of elementary row operations cleaner, and because it allowed the more natural syntax of indexing the matrix as though it were a 2D array. There are two usability features that my implementation provides which yours does not. The first is being able to index a vector by name (_x, _y, _z, _w). This is easily implemented using a properly scoped enum. I used leading underscores for my component names as a convention to indicate that they were property names, though admittedly this naming convention could be debated. vector <float, 3> up; up[_x] = 0; up[_y] = 1; up[_z] = 0; Another thing that my code allows that yours does not is explicit construction of a vector from the number of parameters that matches the size (at least from 1 through 4), using the SFINAE techniques of boost.enable_if. It can be much nicer for client code to be able to write: vector <float, 3> up (0, 1, 0); than to have to write the code segment I used for my previous example. Just a few thoughts. -Jason