On 11/10/06, Jason Kraftcheck <kraftche@cae.wisc.edu> 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