I agree with this, but I was thinking more of something
on the level of the generic "vector" class
in STL i.e. a matrix class
which handles the basics of allocating and freeing
2D (or n-d) arrays , setting and retrieving elements, defining
operator overloading for the basic operators,
doing common operations like the transpose.
That doesn't give you a wide range of functionality, but
it does mean that there is a well-designed standard
and it is one step along the way to more portability.
Paul.
owner-oon-digest@oonumerics.org writes:
>
> oon-digest Saturday, 26 July 1997 Volume 01 : Number 010
> ------------------------------
>
> From: "Richard Weidner" <richard@spartacus.jpl.nasa.gov>
> Date: Wed, 23 Jul 1997 09:43:04 -0700
> Subject: Re: OON: matrix and vector classes
>
> 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?
> >
> > 2. Is there any sign of a library which is likely
> > to be supported and developed for a significant length
> > of time e.g. something which is being considered for
> > the ANSI C++ standard?
>
>
> Those are interesting questions. At face value, they would appear
> to pose a concept that would be of interest to all of us. The idea
> of the biggest, most extensive, most generic library would have
> some merit. A library so all encompassing as to become the standard
> for all work.
>
> 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.
>
> I do not believe there is a generic library that is the most efficient
> implementation across all applications that use matrices and vectors.
> Thus a "most extensively implemented" library sounds as though the
> library became a goal in itself, and the efficiency requirements of
> the application got lost.
>
> As an example, consider the infamous matrix inverse so overworked
> in the last three decades. Say that your application creates
> matrices of a definite small size that are never stiff. (Rotations
> for example.) Now say you get a generic library that works for
> large matrices that are stiff (ie a library built for regression
> analysis.) The algorithm would be very inefficient for inverting
> a rotation matrix. Granted you could put in different inversion
> methods, but in practice people would not know which one lurks
> behind an operator. And who needs all of the extra baggage
> when you never use it? (There are ample examples of superfluous
> functionality with all of the inherent inefficiency in
> the old Fortran libraries.)
>
> In short, more appropriate questions would query what matrix and
> vector libraries are available for application area X. Which one is most
> commonly used and meets the requirements of application area X.
> What is the reliability of that library and what future support
> will be available? I would like to know the answer to those questions.
>
> PS: Maybe we could call these minimally implemented libraries. Just
> the functionality you need, tuned specifically for your needs,
> and nothing else. There is certainly a cost benefit to creating
> and maintaining minimal libraries if your goal is the application
> and not the creation of a library. The source of contention is
> of course defining the minimal set for all of your needs.
>
> - --
> Richard Weidner
>
> ------------------------------
>
> End of oon-digest V1 #10
> ************************
>
> --------------------- Object Oriented Numerics List --------------------------
> * To subscribe/unsubscribe: mail to majordomo@oonumerics.org, with
> "subscribe oon-list" or "unsubscribe oon-list" in the body of the message
> * Digest format available: "subscribe oon-digest"
> * OON Web page: http://oonumerics.org/oon/
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:05 EST