OONSTD: objections

E. Robert Tisdale (edwin2@gte.net)
Fri, 04 Sep 1998 10:03:36 +0000

Since all of the C++ numerical class libraries will depend upon
the C++ Scalar, Vector, Matrix and Tensor class libraries,
we will probably need an SVMT class library standard
before any substantial progress can be expected
on the other parts of the numerical class library standard.
I have proposed a standard for the SVMT class libraries
and no one has offered any strong objections to it so far.
I suppose this is mostly because my proposal simply extracts
essential common features from recently available class libraries.

Some people think that SVMT classes should be implemented as templates
but I think that decision should be left up to the library developer.
Some people think that array class templates should be standardized
(i.e. SubArray<class T, int n>) but no one has offered a formal proposal.
I think that array class templates are just fine
but there is no way to standardize specializations
for all the different type parameters T
which application programmers might find useful.
You might want to think of the SVMT class library standard
as a specification for specializations
for numerical types T = float, double, etc. and dimension n = 0, 1, 2 or 3
but I don't want to preclude just yet the possibility that SVMT classes
and the corresponding array template classes might have different meanings.

Some people think that the SVMT class library should offer more features
but I would rather keep the SVMT class library small.
I think many of the features offered by other matrix class libraries
really belong in other parts of the standard C++ numerical class library.
Other embellishments which are not essential to efficiency or performance
but might be convenient for application programmers should be provided
by an `adaptor' classes derived from the basic SVMT classes.
Perhaps there should be a standard for these adapter classes.

Everybody seems to have different ideas about indexing
but there are actually just two types of indexing
which most people consider for C++. One, of course,
is C style indexing and the other is a pseudo-Fortran style indexing

C Fortran
-----------------------------------------------------------------------
base index 0 1
ordering row major column major
indexing operator [] operator ()
sections slice(start, size, stride) lower: upper: stride

but some people want to mix them together and others want to use both!
I prefer the C style indexing because this is, after all, a standard
for C++ class libraries.

Some people think that the application programmer needs to write
for loops which reference the individual elements of an array
but I believe that one of the objectives of the SVMT classes
is to eliminate the need for such loops. There are just too many ways
the application programmer can make mistakes when writing for loops.

No one seems to object to the data abstraction -- subscalar, subvector,
submatrix and subtensor objects are simply different views of a 1D array.
This isn't surprising because it is so easy to calculate the location
of each and every element on the fly from a tiny amount of information
stored in each object.

The thing that astonishes me is that no one objects
to independent strides for every dimension.
Strides are not new but many existing class libraries
restrict one dimension to unit stride.
Other class libraries place restrictions on the stride
in multi-dimensional arrays so that it isn't possible
to reference the same element with different indices.

Some people think that there should be a standard for sparse arrays
but no one has proposed a formal standard.
I have found that it is very hard to justify special algorithms
for sparse arrays unless they are very large and very sparse.
Special provisions for triangular matrices, for example,
are usually just a waste to time and effort.

Some people think that expression templates should be used
to optimize performance. I think that expression templates are a great idea
but I don't think the standard needs to specify expression templates
or any other performance optimization technique and probably shouldn't.
Performance optimizations like expression templates should be transparent
to the application program and left up to the library developer.

Bob Tisdale <edwin2@gte.net>