Re: [boost] 2D Matrix

From: Jason Hise (0xchaos_at_[hidden])
Date: 2006-11-08 17:00:34

On 11/8/06, Jason Kraftcheck <kraftche_at_[hidden]> 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