Re: Standard Matrix interfaces

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2001-08-21 02:37:07

Hi,

Helmut Zeisel (helmut.zeisel_at_[hidden]) wrote:
> If it is used for writing new algorithms from scratch,
> you are right (although I doubt whether efficient
> algorithms can be written without knowledge e.g. whether
> the matrix is stored row by row or column by column).

If you cannot implement algorithms effeciently on the basis of the
generic interface, the interface is broken and shall be improved.

> My personal primary need
> (which might be different from boost's need)
> is to access existing libraries.

Functions applied to the data structure may have a generic
implementation but for special purposes, the function may be
specialized (actually, this is technically not correct, it is actually
overloading, but I think specialization is the better term to
understand the intend the purpose) to use existing implementations
instead of the generic version. That is, you would manipulate the
stuff using the generic interface and it's corresponding algorithms
but underneath a different implementation is used where applicable
and reasonable.

For the purpose of Boost I think the generic interface is the key
part. It should be possible to use data structure specific
implementations for functions underneath but the interface to the
functions should not differ from the generic version. If it turns out
that specific functions from existing libraries do not fit into this
approach, it depends on the benefits of the generic interface whether
this is acceptable.

BTW: In STL there are "algorithms" which are actually not algorithms
at all! For example, "sort()" is called an "algorithm" but it is
actually more a "solver" for a particular problem (bring a sequence
into a certain order). A specific approach to implement this solver
is an algorithm, eg. "quick sort", "bubble sort", "merge sort" etc.
are "algorithms". The same solver can be implemented using different
algorithms to tailor the solver to particular knowledge about the
data structure. For example, the solver "sort()" can be implemented
using "intro sort" for random access data structures and using
"merge sort" for bidirectional (and possibly forward) data structures.

The same confusion between solvers, algorithms, and their
implementation will probably arise with matrix libraries, too, and
it already does with graphs as far as I have seen. I think we should
define such terms precisely such that we can talk more clearly about
these issues. Unfortunately, I'm not particularily comfortable with
the term "solver" used in the text above but I can't think of a better
term, almost certainly due to the fact that I'm not a native English
speaker...
--
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de