
Boost : 
From: walter_at_[hidden]
Date: 20010328 15:34:48
Hi Jeremy,
you wrote:
> I've taken a quick look at your matrix library. You and Mathias
have done
> a nice job!
Thanks.
> I have some trivial differences of opinion about parts of the
interface,
> but much of the design looks right. Since this is a prototype, I
won't
> comment on too many implementation details, though one particular
gotcha
> caught my attention: at least some of the iterators were not std
> conformant.
Standard conformance currently seems not to be as important as other
things :).
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(),
and
> 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 rank3 tensor for example?
> Also, your matrix class almost has a containerofcontainer
interface, but
> not quite. Why not go all the way?
We did not pay too much attention to the containerofcontainer
interface. The motivation was to get some compatibility with Carray
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
> densematrixasadatastructure interface should just be the exact
same
> interface as a 2D multi_array... the only difference would be that
the
> matrix class would inherit from matrix_expression so that it would
have
> all the basic linear algebra operations (thereby fullfilling the
> matrixinalinearalgebra interface). Similarly for vector.
Agreed, there certainly should be as much compatibility as possible
between a matrix and a multiarray 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
> matrices?
Yep. We hope to be able to modify iterators and evaluations to
utilize sparsity.
Best regards
Joerg Walter
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk