I don't regret the internal representation of valarray<>. What I
regret is the standardization of a class interface designed to solve a
problem that has turned out not to be very important. As a container
for numbers to be crunched, valarray<> is fine, though rather obvious,
and somewhat redundant with vector<>. As a concrete data type,
valarray<> is full of operators that invite a programming style that is
sure to flush a lot of caches a lot of the time.
> What happens if valarray<> is deprecated.
Write your own. The container aspects can be recreated in about
fifteen minutes if you are at all competent.
> If computer architecture evolves to favor a different representation,
> all the application programs that rely on access to the underlying
> representation would suddenly become obsolete.
Unlikely to happen. The von Neumann machine with linear address space
is one of the most brilliant inventions of the last thousand years.
We've all seen attempts to do it differently (can you say "8086"?) and
I can't believe any of us were impressed. Given that computers will
continue to have linear address spaces, there's only one rational way
to lay out a vector.
Caveat #1: You are working with a sparse vector and want a compressed
representation. Any care to post an example? (I'd be really interested
in studying any application in which this would be useful.)
Caveat #2: Distributed containers. I think these are a really bad idea,
but I've been surprised before.
> If Roscoe were a commercial library developer,
> he wouldn't be able to sell any more packages
> and he would probably have a large number
> of very angry customers attempting to sue him.
>
> The library developer SHOULD hide the actual data representation
> and provide implementation independent methods
> which the portable application programmer can use to access data.
There's no such thing as an implementation-independent method to
access the data underlying a container. The best you can hope for is
an implementation-independent spelling. There are only two ways to
do this:
1. You container is a descendant of some abstract container class,
and the methods are virtual (data polymorphism). This implies an
enormous overhead to access the data.
2. Your algorithm is generic and relies on nothing other than the
spelling of the method (functional polymorphism.) This implies exposed
source code.
The first is a fundamental problem, because few people care about numerical
calculations that are not pushing the envelope, and calculations that are
pushing the envelope have to be fast. If you can implement a much faster
algorithm by using a slightly slower container, you win, but I don't see
virtual access methods as only slightly slower, nor do they seem like
something that would make it easier to implement much faster algorithms.
The second is perhaps something we don't care as much about. It's a
killer in a commercial market (no one wants to distribute commercial
source code) but, by and large, we're not talking about a commercial
market here.
> There is no way to deny the application program direct access
> to the underlying data representation but the library developer
> is not obliged to support application programs which do so.
Unless the library developer promises to maintain the representation.
>
> It is important to distinguish the role played by the library developer
> from the role played by the application programmer.
> So far, Roscoe has been playing both roles and he wants to continue doing so.
> That's fine as long as he is the only one using his library.
> If he decided to change the underlying representation,
> he could just change all of his applications as well.
> But I hope, if he has convinced someone else to use his library,
> he would consider what effect changes in his library would have
> on their applications and devise some scheme to ensure
> that the impact would be minimized.
By playing both roles, Roscoe at least has the assurance that the
library developer is listening to the applications programmer and
trying to give the latter what he wants.
>
> The actual data representation is irrelevant to the application programmers
> if the library is complete and well designed but if they discover
> a deficiency in the library, they may require direct access to fix it.
> In this case, the application programmer switches hats
> and becomes a "library co-developer"
> in an implicit partnership with the original library developer.
> Usually, application programmers can get all the cooperation they need
> from the library developer as long as they don't require any additional
> commitments from the library developer.
Again, this assumes you are using either templates or virtual functions
to provide a common spelling of the interface.
>
> > Other C++ matrix libraries like TNT, LAPACK++ and others
> > offer some of these features but not all of them.
> >
> > All I want is a fairly efficient and sensible interface for linear algebra
> > computations that will be compatible with existing software (Fortran).
> > And for developers to get their work done they need more than just nice
> > vector and matrix abstraction classes but an entire set of linear algebra
> > operations.
>
> I think these requirements are typical.
> The libraries must have a fairly complete set of capabilities.
> It won't really help much to standardize a "bare bones" template class
> and leave all the specializations up to the application programmer.
> We really need to standardize all the specializations
> for the all types that are of general interest to scientists and engineers.
I only expect to live another 40 years or so. I don't think I have time to
standardize all the specializations that are of general interest. Actually,
I'm not sure that _specializations_ of _general_ interest isn't an oxymoron.
>
> Bob Tisdale
>