>It would be better to say that caution should be exercised against
>assuming any one approach is a panacea for all design goals.
>You simply can not create a single library or set of functions
>that solves the general linear algebra problem.
>...
>10,000,000 x 10,000,000 matrix to start getting the idea. Hopefully,
>you will not use that code on a 3x3 matrix.
Sure, I would totally agree, but let's separate out implementation from
interface for a second. The product(B,C,A) interface efficiently handles
both 10Mx10M matrices and 3x3 matrices (whether the code on the other side
of it does is quite another issue). I haven't seen an A = B*C interface
that can handle the big matrix efficiently without a lot of extra work on
the interface designer's part, if at all. So, leaving "oo-ifying"
undefined, was it worth it to oo-ify this interface?
If it was not, then what exactly is oo-numerics anyway? Is it just an
normal oo program for all the non-numerical parts that then calls a non-oo
BLAS whenever it wants to multiply matrices? That's not necessarily very
interesting.
I guess I'm thinking pretty selfishly here, but the problems I run into each
day are how to convert an equation like A = J*M*J^T into efficient computer
code. The naive approach in C++ is:
matrix A = J * M * Transpose(J);
Which creates a zillion temporary matrices and doesn't take advantage of any
of the structure (M is diagonal and J is block sparse). If, to get
performance, I'm forced to write:
DoMyOperation(J,M,A); // computes A = J*M*J^T, M diagonal, J block sparse
the what did I gain from going to an oo language (in this section of the
program)?
Now, some people (and even some oo books) will argue it's possible to
generate efficient code for the first expression by doing some wacky
lazy-evaluated expression objects and the like, or maybe by using some
really stoked reference-counted matrix classes, but jeez, that's incredibly
complicated compared to the second expression, and not likely to be as
efficient.
Chris
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST