The second shoe drops
It's time to wrap up the series on matrices. I think I'm finally close enough to be able to give you a matrix class that's serviceable.
Because this series has been strung out so long (see the sidebar--the first matrix article I wrote was "Who needs matrices?" in the December 2007 issue of Embedded Systems Design), I'll take the time to recap where we came from and where we've been.
For decades, I've been wanting a language that would let me do arithmetic with vectors and matrices, like this:
Vector x, y, u; Matrix A, B; ... y = A*x + B*u;
I first suggested a vector class in the August 2006 issue ("Loose ends," page 14). In it, I showed a usable structure representing the mathematical entity called a vector. Over the next few issues, I developed the class until I now consider it complete. During the process, I showed you a few cases where use of vectors can make life bearable.
In the December 2007 issue ("Who Needs Matrices"--again I refer you to the sidebar for links), we wrapped up the Vector class and began the definition of a matrix class. Consider this the last issue in that series. At this point, I think we are close enough to a complete matrix class that we can wrap it up and declare victory. This is not to say that there is nothing left to do. The world of vectors and matrices is a rich, rich world, with a huge set of operations one can do with/on them. I could never in my lifetime give you code for every kind of manipulation one can do with them. Even then, there would still be the ones I've never even heard of.
A syllabus: matrix and vector math
Jack Crenshaw has devoted many of his columns for the last 2 1/2 years to vector and matrix math. Here's a list of what he's written on vector and matrix math, with links to the online version.
"Motivationally speaking," October 2006, pg. 15, www.embedded.com/193402564
"Making the tough coding decisions," December 2006, pg. 9, www.embedded.com/196601281
"SimpleVec wrap," February 2007, pg. 11, www.embedded.com/197002378
"On to objects," April 2007, pg. 13, www.embedded.com/198701651
"The vector class," June 2007, pg. 13, www.embedded.com/199703501
"Completing the vector class," August 2007, pg.13, www.embedded.com/201202113
"Vectors--the last word," October 2007, pg. 9, http://www.embedded.com/202102663
"Who needs matrices," December 2007, pg. 11, www.embedded.com/204300487
"Why multiply matrices?" February 2008, pg 9, www.embedded.com/205918951
"The matrix reprogrammed," April 2008, pg. 9,
"Fleshing out the matrix class," June 2008, pg. 14, www.embedded.com/208400912
"Reusing code and inverting matrices," August 2008, pg. 11, www.embedded.com/209600564
"A funny thing happened..." December 2008, pg. 9, www.embedded.com/212200180
In my experience, it's always a mistake to try to anticipate every possible use one should expect, or every possible feature one might need, in a piece of software. I tried that approach once before, long ago. As I was building a huge simulation of a tank-mounted rocket launcher, I'd ask my boss "Do you think we should include the effect of (mass imbalance, thrust misalignment, rocket asymmetry, etc., etc.)?" His answer was always yes. I put all those effects in, with added parameters to define the additional effects. During the life of the program, not one simulation run was ever made with anything but zeroes in those parameters.