: "Richard Weidner" <richard@spartacus.jpl.nasa.gov> wrote:
: |On Jul 23, 9:36am, Paul Beardsley wrote:
: |> 1. What is the most extensively implemented library for
: |> matrix and vector classes at the moment, which uses the
: |> STL generic approach?
: |>
: ..
: |My experience is that such a beast is not really a good idea.
: |It can never be efficient for every practitioner.
: ..
: |I am not saying a standard library is a bad idea. I would think the
: |best, most extensive library for regression analysis would be useful.
: |The people who work in that area may have found a common implementation
: |that uses the STL generic approach that is efficient for them.
: |................................................................. But I
: |can guarantee it would not be the best approach for people doing computer
: |graphics.
And surely any attempt to define a LINPACK for computer graphics and general
purpose numerical computing would fail. But why not a generic LINPACK?
: (many thoughtful comments clipped)
: Perhaps what would be required is not to use the STL techniques
: (necessarily), but to use the STL philosophy. That is, the user has the
: ability to choose the implementation based on what would be most
: appropriate for their use. For instance, I can choose to store data in an
: STL list or a STL vector depending on whether I want to insert often and
: don't need random access (in which case the list is better), or if
: insertions will be rare and I need fast random access (in which case the
: vector is better).
: Such a system would require:
: a) a lot of up-front design or prototyping (as I understand STL did) to
: find a way of making it work efficiently while allowing the user choice of
: representation and algorithm, and
Some heavy commitment to making the numerics as portable as possible. This
carries with it many benefits, particularly if the commitment remains to
make the package fast independent of target architecture -- as long as the
target is a general-purpose architecture (rather than vector machine or
multicomputer).
: b) an awful lot of development work, since providing multiple
: representations and algorithms would considerably increase the size of the
: task when compared with a "normal" numerical library.
I'm not sure I agree -- I agree there would be a lot of work, but it would
simply take time rather than many people. Again, LINPACK is offerred as
an example.
: Apart from the clear advantages described above, however, the system would
: have the advantage that it would be somewhat usable in a part-completed
: state - e.g. if the first sets of algorithms and representations emphasised
: efficiency for some particular class of problems, then it would be useful
: for that class of problems relatively early in its development.
: Two important difficulties occur to me, however:
:
: 1) doing a random access on an STL list representation will be slow but it
: will still work; on the other hand, using an algorithm suitable for a
: matrix that is (say) positive-definite on one that does not have that
: property could give a seriously wrong answer. Perhaps the system should
: just provide algorithms to check these sorts of properties and trust the
: user to use them if the user is not sure of them.
To try to make a package smart enough to second guess inappropriate usage
is, IMO, an exercise in total futility. There will always be some people
who try to use mathematical components as "black magic", particularly in
my discipline (statistics). There's very little that can be done to defend
against this.
: 2) It may be that given the efficiency constraints of numerical software,
: any system as flexible as STL would be unbearably inefficient for any
: real-life problem.
Again, I offer LINPACK as a counterexample.
: - Simon Lovatt
Jan Theodore Galkowski,
Digicomp Research Corporation.
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST