|
Boost : |
From: boost (boost_at_[hidden])
Date: 2001-04-02 15:15:03
Salut,
[...]
> > This isn't really a conceptual difference, just a difference in
> > packaging. It's interesting, but it produces iterators that are not std
> > conformant. If I see iterators, I want to be able to use them with
> > std::copy(), etc.
>
> I'm not sure about this. After all, a 2D array is conceptually very
> different from a sequence. This is reflected in the 2D iterators. In
> addition to them, I've lots of iterator adapters that realize different
> mappings from 2D to STL-conformant 1D sequences (e.g. ScanOrderIterator,
> RowIterator, ColumnIterator, ContourFollower)
>
> > Also, there might be some performance advantage in the "hierarchical"
> > approach because the index*extent multiplications can be moved to outer
> > loops, effectivly performing what compiler guys call strength reduction.
> > With the above iterators, you might as well just use the index objects
> > instead.
I would be glad if there would be the possibility to itterate ober the
elements of a "D array with out the performance loss of a the "index*extent"
(e.g. nx* DImX + ny ) adressing.
I'm using 2D matrices to represent 1D (dyadic) vectors in the inner loop
of a very large sparce matrix diagonalization. (The matrix itself is
a collection of matrices operating from the left and the right on my
vectors). In addition to matrix-matrix multiplications I need to be able
to iterate of the the elements of a vector consisting of a list of 2D arrays.
(The dimension of the vectors is >10^7 ).
[...]
> Which would be very much simplified if "x[i] = a" weren't a requirement.
> How about this:
>
> x.set(i, a) is required.
> x[i] = a is optional
>
> This means that
>
> 1. If a data structure can implement "x[i] = a" efficiently, it shall do
> so
> 2. A truly generic algorithm should only use x.set()
> 3. If you know that all your data structures implement "x[i] = a", you
> may use it everywhere.
I think that's fair.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk