Re: [boost] Re: matrix library ?

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2001-03-14 10:28:35

"David Abrahams" <abrahams_at_[hidden]> writes:

| ----- 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?

There are plethora of terminologies in numerics and one has to be very
careful :-(

I'll call a library a "Linear Algebra Library" if it provides direct
support for all BLAS levels facilities; those include trivial stuff
like level-1 and level-2 operations as well as matrix decompositions.

| > 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.

There is no single way to get right a numerical library :-)

I've for some time disagreed with design decisions made in Blitz,
but I can assure you that as time goes I learn to understand
those choices -- not that I agree with them (I still disagree with
overloading operator, :-).

As a general rule, it is felt that for better performance, memory
management should be separated from algorithms in basic building
blocks (pretty much the same way standard algorithms don't manage
memroy directly). 

One can see the problem from a type perspetive: Two array objects with
different shapes are instances of (conceptually) two different types
(that matters for matrix operations) and implicit conversions should
not be tolerated.

| > 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? 

Yes.

-- Gaby