Re: [boost] 2D Matrix

From: Jason Hise (0xchaos_at_[hidden])
Date: 2006-11-10 14:19:21

On 11/10/06, Jason Kraftcheck <kraftche_at_[hidden]> wrote:
> I think that the two important issues here are:
>
> 1) Boost should have these types defined outside of any domain-specific library.
>
> I think they are equivalent to other types such as complex numbers, and should exist
> as primitives for use in many different libraries.  There seems to be some
> support for this from others:
> http://lists.boost.org/MailArchives/ublas/2006/11/1519.php

Vectors do seem to be important as a primitive foundation for many
things, including complex numbers, quaternions, colors, and matricees
;)

> 2) Should a vector be defined as a column matrix or a separate template.
>
> This is the principal differentiator between your implementation and mine.  The
> other issues are just simple features that can be added to one or the other.
>
> My argument for a column matrix definition of a vector is that it is closer to
> the mathematical concept we are trying to model.  All matrix operations
> (multiplication between vectors and matrices, transpose, etc) work for vectors
> as well as matrices w/out needing special vector forms of the operations.

Although I understand the desire to merge the matrix and vector into a
single type in order to shrink the interface that must be implemented,
and though it may make sense from a mathematical and/or efficiency
standpoint, I do not think that it makes sense from a design or
extensibility standpoint.  Good designs tend to compose more complex
concepts from simpler ones, rather than defining simpler concepts as
special cases of more complex ones.  Generally, programmers do not
tend to view floats as complex numbers that happen to have a zero
imaginary component, or view ints as floats that have nothing
following the decimal point, even though that is the mathematic
concept being modeled.  If I were defining a color class based on a
vector, I don't think that it would occur to me that I was defining a
specialized matrix that only had one row.

Also, consider the library from a dependency standpoint.  People that
need vectors may well not need matricees.  But people that are using
matricees are very likely to need vectors as well.

> My understanding of your argument for vectors as a separate class is that it
> allows the matrix class to be defined as an array of vectors, where each vector
> is a row of the matrix.  This, in turn, allows for simpler coding of matrix row
> operations for algorithms such as Gauss-Jordan elimination.

Yes, but it is more than that.  It seems to me that a vector is not
just a specialized matrix, but is a type in its own right which
supports its own operations.  Matrix multiplication is not defined
between two vectors of the same orientation, and vector multiplication
does not apply to matricees.

> My implementation also provides row access to matrices as 1xC matrices, and
> provides vector specific operations (vector product, dot product) for both Rx1
> and 1xC matrices.

This means that you are supporting two different types of vectors.  So
which type should be used as the foundation for vector based types,
like complex numbers and colors?

> The only drawback to my approach is that a reinterpret_cast
> is required to return a reference to a row as a 1xC matrix.  It is portable to
> do so, as the underlying cast is just operating on array data (no alignment
> issues for individual members, no vtable, etc.)  But it is ugly.

This issue arises directly because of the fact that a matrix
conceptually is a compound type, whose components should be acessible
to client code.  But a matrix is not just a compound type composed of
elements.  A matrix is composed of rows of elements.

-Jason