Perhaps the right way to say this is that valarray<T> was the solution
to the wrong problems. I originally designed it largely with vector
supercomputers in mind, but hardly anyone uses these anymore. Its
design assumed that a major goal of numerical C++ programmers would be
to get rid of explicit loops, but that also has turned out not to be
very important. STL has shown that loops and iterators can be
beautiful, and so can containers other than arrays.
However, none of this was clear at the time valarray<T> was proposed.
Vector machines still seemed very much alive (there was even talk of a
massively parallel machine based on vector processors.) It seemed like
*everyone* was building Yet Another Smart Array Class for numerical
computing, and they all seemed to feature operator overloads that
eliminated the need for clients to write any loops. None of these
classes worked very well, and there was a sense that some kind of
compiler magic was required to make the things efficient. The best way
to get such magic out of the compiler writers seemed to be to add an
array building block to the library towards which compiler writers
could direct their optimizations. This attitude led in turn to the
sense that if we didn't get *something* into the standard library,
before the deadline for producing a committee draft, we'd miss the boat
entirely.
This picture changed rather abruptly when template expressions were
discovered. These *do* work well, without any compiler magic (beyond
that required to get templates right, a seemingly still-elusive goal
for the developers of the compilers I'm forced to work with) and,
with their discovery, valarray<T> ought to have been quietly dropped.
Unfortunately, the committee instead chose to retain valarray<T>, but
loosen its specification so that it could optionally be implemented
using expression templates. This was a mistake. I'm sorry I didn't
do more at that time than to hesitantly suggest that valarray<T> ought
perhaps to be dropped. I was no longer on X3J16 by then, but I still
could have wielded some influence to get valarray<T> killed, and I
didn't. (There was probably an element of pride involved; no healthy
person likes to strangle their own child.) I apologize for that.
The most fundamental objection to valarray<T> is that it wasted a lot
of time and energy belaboring the obvious. This class provides an
exhaustive list of every possible operation one would want to perform
on a one-dimensional array of data, but that's of no great interest.
The right layout for column matrices is not controversial. What would
have been more interesting, as others on this thread have pointed out,
would be standards for the architecture of multi-dimensional arrays
(tensors of various ranks.) Of course, one then wants standards for
various flavors of sparse matrices, and soon the standardization task
becomes fairly burdensome.
I think the right answer is clever generic algorithms rather than clever
classes. The standardization effort will then shift to ensuring name
commonality in the interfaces of matrix classes. I think this is a fairly
tractable task.
>
> Maybe most importantly, who would implement a standard scientific
> computing C++ library? Compiler vendors? Standard library providers
> (e.g. Rogue Wave)? What would be the economic incentive for them to
> do so? Scientific computing is a very small market segment for most
> compiler vendors. And the standard library you propose would be
> very expensive to implement.
Quite right. Even valarray<T> drew strong objections from the
Microsoft/Borland crowd, for the very understandable reason that it
costs significant money to implement and 99% of their customers would
never use it. If I'm not mistaken, Rogue Wave dropped further development
of Math++ for precisely this reason.
>
> Maybe defacto standards are a better way to go. Look at
> how successful BLAS, LAPACK, IMSL etc. have been. They are portable,
> widely available, and offer high performance.
Right. LAPACK++ is already being developed. Dongarra and his collaborators
have presented some interesting papers on this topic, at OONSKI/OONSCI,
POOMA, and elsewhere. (Forget standardizing array classes. We can't even
agree on a name for the annual conference for numerical C++. :-)
Kent G. Budge
Sandia National Laboratories