Re: [boost] Re: matrix library ?

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-13 17:17:27

----- Original Message -----
From: "Ronald Garcia" <rgarcia4_at_[hidden]>

> For the sake of clarity, I should mention what kind of library I am
> working on.  Primarily, I'm developing a multidimensional array library,
> rather than a matrix library per se. That is, things are more similar
> to Blitz++ than MTL, though access to matrix functionality is
> definitely a requirement.

Phew, the terminology is making my head spin. Andy calls MTL a "linear
algebra library", clearly distinguishing it from a "matrix library", but you
seem to be calling it a "matrix library". Could someone please clearly
delineate the distinctions here?

> I am also focussing strongly upon portability across C++ compilers.
> Performance must be reasonable, but not in a manner such that some
> platforms cannot make use of it.  The reasoning is that if you need a
> high-performance multi-array library, Blitz++ is already available;

True, though my limited exposure to Blitz++ leaves me a bit unsatisfied with
the design. For example, see
http://www.oonumerics.org/blitz/manual/blitz02.html#l50.
Perhaps this design choice is justified, but if so it is a little unclear to
me why it should be so.

> likewise, if you need a high performance matrix library, MTL is
> already available (not to mention other great libraries such as
> POOMA).

And though POOMA documentation is rich in introductory materials, there
appears to be no comprehensive reference manual (?)

> But there is a need for a library that can be used rather
> ubiquitously.

I wonder. In domains where problems of this scale really count, isn't it
pretty much always important to get the best performance possible? And
wouldn't that justify switching compilers (e.g. to Intel C++), at least for
the matrix code?

> I think that expression templates/mathematical notation should be
> optional.  I've seen some previous work on this kind of thing and I
> thikn it can be provided as an extra layer upon a procedural interface
> without loss of efficiency.

That seems plausible.

-Dave