It's guaranteed that the elements in valarray<> are stored sequentially.
...
> >
> > 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 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.
> >
>
> Does anyone think that it is unreasonable to say that:
>
> "The data elements that VectorSlice provides a view into are, and forever
> shall be stored in a continous array separated by stride possitions."
Not at all. It makes for good optimization and gives you at least
a fighting chance to control what the cache is doing.
>
> Fortran and the BLAS have gotten by with this for decades. This brings up
> another point. Why do we even bother writting C++ class libraries for
> dense linear algebra when the data stuctures we are abstracting are the
> simplest you can imagine? Is it really encapsulation we are going for or
> is it abstraction?
BINGO!
Actually, I'm not that interested in dense linear algebra. Sparse linear
algebra is of much greater interest for my applications. But if I was
going to ++ize dense linear algebra containers, it would be for one of
these reasons:
1) Automatic handling of memory management
2) Clean interface to various operations
3) Because my library expects a container class.
Automatic handling of memory management is probably not very important
in the long run. I predict that C++ will eventually mandate garbage
collection, and the default operator delete will become a no op. In
the short run, of course, there is some very sophisticated memory
management going on out there. Including (very platform-dependent)
third-party garbage collection libraries. In fact, the possibility of
third-party garbage collection was used as an argument against
mandating garbage collection in X3J16. "It isn't always a good idea,
and anyway users can implement it themselves if they really want it."
(And _really_ know their machine.)
Clean interfaces are obviously a good thing, assuming they don't screw
up efficiency. But the emphasis is on "clean" (the abstraction aspect)
rather than on "interface" (the encapsulation aspect.)
And the third reason for using ++ized dense containers is most relevant
in an arena full of generic algorithms. This is another form of abstraction
(it's hard to see what generic algorithms have to do with encapsulation.)
...
>
> The library user should be able to neglect the libraries implementation of
> an operation and implement his or her own if they feel like it and be
> assured the it will still be applicable in the next version of the
> library. Remember, we are talkine about dense linear algebra here where
> the most complicated data structure is:
>
> double A[], size_t m, size_t n, size_t lda
I agree completely.
>
>
> If anyone is interested I have set of standards that I have been working
> on for my own libraries. I have put a lot of work and thought into them
> and will distribute the html files for them if desired.
>
> (1) Naming sceme for linear algebra operations supported by functions that
> is: a) consistant, b) compact, c) easy to translate from the mathematical
> notation to the function identifier name.
>
> (2) Template class specifications (compile time polymorphism) for a)
> sparse unstored vectors of the form (val,i) and b) sparse unstorted
> coordinate matrices of the form (val,i,j).
>
> (3) Abstract interface to matices and Level-2 and 3 BLAS operations using
> virtual functions to used when runtime polymorphism is needed.
>
> Matrix (rows, cols)
> |
> MatrixWithOp (y = alpha*op(A)*x + beta*y, Y = alpha*op(A)*op(B) + beta*Y)
> |
> MatrixWithOpFactorized (y = alpha * inv(op(A)) * x, ... )
>
I'm looking forward to seeing the details.
>
>
>
> --------------------------------------
> | Roscoe Bartlett |
> | Ph.D. student |
> | Department of Chemical Engineering |
> | Carnegie Mellon University |
> | email: roscoe@andrew.cmu.edu |
> --------------------------------------
>
>
Kent G. Budge
Sandia National Laboratories