A standard Application Program Interface (API) is required if you determine that

it isn't practical to implement a high performance small vector class library
that is portable to every target platform that you wish to support.
The standard API would permit independent small vector class library developers
to implement high performance small vector class libraries customized
for a particular platform that would still support portable applications
which use the standard small vector class library API.

You need to provide two things:

1. a document which specifies the small vector class API and

2. a [portable] small vector class reference library.

The API specifies two things:

1. the underlying Abstract Data Types (ADTs) and

2. a language binding for each target language.

Even though you have identified just one target language binding,
you should specify the API without regard to any language binding
or implementation of any particular language binding.

The purpose of the reference library is to help
small vector class library developers verify the correct behavior
of their own high performance implementations.
It need not be a high performance implementation itself.
It should probably be as straight forward, transparent
and easy to maintain as possible
because you probably won't be able to get money
to pay for maintenance.


Stardardization of large vector and matrix library APIs
has been going on for a very long time so it might help
to look into some of them in order to get an idea
of what needs to be done.

Check out the archives of
the Basic Linear Algebra Subprogram Technical (BLAST) Forum

    http://www.netlib.org/blast/index.html

The scope of the BLAS library and
the Linear Algebra PACKage (LAPACK)
is restricted to linear algebra
and the C++ language binding LAPACK++
is nothing more than a set of thin interface adapters.

The Vector, Signal and Image Processing Library (VSIPL)

    http://www.vsipl.org/

has an ANSI/ISO C language binding and
an ANSI/ISO C++ language binding is in the works.
The scope of VSIPL is restricted mostly to
Digital Signal Processing (DSP) and more specifically
to embedded Digital Signal Processor (DSP) systems.

The Object Oriented Numerics Mailing List Archive

    http://www.oonumerics.org/MailArchives/oon-list/

includes an extensive discussion of standardization
including contributions by Kent Budge

    Re: OON: Usefulness (or otherwise) of valarray for numerical work in C++

who introduced the valarray class template into the standard library.
Apparently, valarray was introduced at a time when super computers
with large vector processors were popular
but compiler developers for these computers never took advantage
of valarray (they just weren't interested in supporting C++ compilers)
which disappointed Kent and caused him to regret proposing
valarray in the first place.  Today, we have very fast little
microprocessors with small vector pipelines -- AltiVec

    http://www.altivec.org/

for example that require extensions to [GNU] C and C++ compilers
in order to support practical applications --
but I am not sure that this is sufficient reason
to make these extensions part of the ANSI/ISO C++ standard
and compel C++ compiler developers to support them.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]