Date: 2001-03-28 15:34:48
> I've taken a quick look at your matrix library. You and Mathias
> a nice job!
> I have some trivial differences of opinion about parts of the
> but much of the design looks right. Since this is a prototype, I
> comment on too many implementation details, though one particular
> caught my attention: at least some of the iterators were not std
Standard conformance currently seems not to be as important as other
We have to check that.
> Perhaps using the iterator_adaptor library would provide an
> easy route to providing complete iterators.
We'll surely have to look at that library.
> The functions whose names end in "1" or "2" like size1(), size2(),
> begin1(), begin2(). This naming scheme was not intuitive to me.
Counted by dimension (or rank?). In an older version they were called
row_size and column_size (as one would expect?). But how would you
name them in a generalization to a rank-3 tensor for example?
> Also, your matrix class almost has a container-of-container
> not quite. Why not go all the way?
We did not pay too much attention to the container-of-container
interface. The motivation was to get some compatibility with C-array
indexing. Using that interface could be more expensive than using
operator (). But to be sure: which functionality is missing?
> Hmmm, brainstorming with Ron here. I'm wondering if the
> dense-matrix-as-a-data-structure interface should just be the exact
> interface as a 2-D multi_array... the only difference would be that
> matrix class would inherit from matrix_expression so that it would
> all the basic linear algebra operations (thereby fullfilling the
> matrix-in-a-linear-algebra interface). Similarly for vector.
Agreed, there certainly should be as much compatibility as possible
between a matrix and a multi-array library.
> Did you provide only left scalar multiplication on purpose, or
> where you planing on adding right mult as well?
It's intended. This is the way we learn linear algebra in Germany :-
). The matrix vector product is currently also only implemented as
left multiplication. This seems to be more problematical.
> Have you had any thoughts about how things would extend to sparse
Yep. We hope to be able to modify iterators and evaluations to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk