Re: [boost] [rfc] A light weight statically typed matrix template class (again?)

From: Andreas Harnack (ah.boost.04_at_[hidden])
Date: 2007-12-10 16:45:53

Dave Steffen schrieb:
> On Thursday 06 December 2007, Andreas Harnack wrote:
>> Hi @,
>>
>> shouldn't there be at least an elementary matrix class available
>> in the standard? I notice there have been some discussions in
>> the past, but there doesn't seem to be anything in the pipeline.
>> So, is there any interest in a (really!) light weight statically
>> typed matrix template class?
> 
>   No, there shouldn't be. :-)

Well, I'm looking forward to a passionate discussion ;-)

> 
>   The C++ landscape is littered with such things, from simpler than
>   your example to fantastically elaborate.  See
>   <http://www.oonumerics.org/oon/> for a sample.

I'd take that as a proof that there is a need for 
standardization, however the result might look like.

>   One of the big problems is that everyone wants something slightly
>   different.  Example:
> 
>>
>> #include <algorithm>
>> #include <functional>
>>
>> template<typename T, unsigned int M, unsigned int N>
>> class matrix
>> {
>>      protected:
>>          T m[M][N];
> 
>   OK, this makes the matrix size a compile-time decision.  This is
>   ideal for some cases and anathema for others.

Isn't that argument a bit like asking, why C++ does have arrays 
at all, instead of just pointers to dynamically allocated 
memory? The huge advantage I see here is that the size is part 
of the type and hence subject to compile-time checks. (That 
doesn't exclude the option to have alternative implementations 
as well.)

>>          T& operator()(unsigned int i, unsigned int j)
>>              { return m[i][j]; }
>>          T const& operator()(unsigned int i, unsigned int j)
>>              const { return m[i][j]; }
> 
>   OK, is that one-based or zero-based?  Some people demand zero-based,
>   others demand one-based.

That's zero based, like any other C++ array or container.

>> There are still a few essential but fairly basic things missing,
>> like matrix multiplication and transposing a matrix. Elementary
>> row operations might be useful as well for those, who want to
>> provide complex algorithms, but that's it, basically. There
>> shouldn't be anything in there that's more complicated than
>> that. (Matrices are such a general concept that it can be very
>> tricky, if not impossible, to provide any guaranties for
>> anything above the basic stuff.)
> 
>   OK, what does operator* mean?  Inner product?  Outer product?
>   Direct product?

As far as I'm aware there's only one product to matrices; we're 
not talking about vectors here ;-). Of course, you can use row- 
or column-matrices to represent vectors, in which case the 
result (i.e. scalar or matrix) depends on the order of operands.

>> Any interest? Comments most welcome!
> 
>   I'm not saying your code is wrong, it's not; it's just fine for what
>   you want.  But it's not at all fine for what the general
>   matrix-using population wants.

Am I really the only one who needs this?

>   As an example of a library that *does* try to fill all those needs,
>   look at Boost's very own UBlas.  Flexible, has all the options
>   covered... and IMHO rather difficult to use, and also rather slow.

Here, I think, we have a huge misunderstanding. I never tried, 
don't pretend I could and don't even want to provide a solution 
that suits anybodies need. I think that's  impossible. I totally 
agree that there are plenty of good libraries out there, some of 
them even excellent. But I refuse to believe, that the C++ 
community consists only of people who do high performance 
scientific computing. For them is reasonably well cared for. But 
what about the rest of us?

>   An an example of a library that probably does exactly what you want,
>   but way way fast, look at 'tvmet'.

Agreed, it does what I want. In fact, any library I looked and 
does what I want because all I want is really simple stuff. I 
just don't like to pay the price (i.e. the dependencies it 
introduces, the complexity that gets involved, the compile time 
overhead etc.).

>   My point is, I guess, that general-purpose one-size-fits-all
>   libraries have historically been hard to use and slow; libraries
>   that are easy to use and fast are not applicable to all uses.  I
>   personally think this issue is rather fundamental to the "computer
>   linear algebra" problem, and nobody has yet come up with The Good
>   Solution (not for lack of work).

I totally agree, but as I said, that wasn't my intention. And by 
the way, talking about matrices does by no means imply to talk 
about linear algebra. It just happens that linear algebra 
peoples are the ones that talk most about matrices. :-)

>   (BTW, I think that UBlas + template typedefs [in whatever form we
>   get them] will grow up to be a big, strong, fast, and very useful
>   library some day.  It doesn't fit my needs at all yet, so I'm using
>   something else).

Nicely phrased ;-). What do you use then?

Andreas