Re: [boost] matrix and vector iterators

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-07 16:01:53

----- Original Message -----
From: "Jeremy Siek" <jsiek_at_[hidden]>

> One thing that we need to decide on is the interface for traversing
> vectors and matrices. I see a couple options:
>
> 1. MTL-style iterators
>
>   *i          // return a matrix/vector element
>   i.index()   // return the index of the element pointed to (for vectors)
>   i.row()     // return the row index (for matrices)
>   i.colummn() // return the column indexn (for matrices)
>
> 2. iterator over "matrix elements" or "vector elements"
>   *i         // returns a matrix or vector element object.
>   value(*i)  // return the element value
>   row(*i)    // returns the row index
>   column(*i) // return the column index
>   index(*i)  // return the index (for vectors)

I assume that *i is then some sort of proxy.

There is also this interface:

3.
  *i  ??    // returns a matrix or vector element object.
  value(i)  // return the element value
  row(i)    // returns the row index
  column(i) // return the column index
  index(i)  // return the index (for vectors)

I think index(i) makes sense even for iterators over the major dimension of
a matrix.

I think Joerg and Mathias are concerned with higher-dimensional matrices
(although I am not), which makes "row" and "column" hard to justify.
Personally, I find it very helpful to have "row" and "column".

I very much like the free function interface, but there is always the LWG
225/229 issue to be aware of. I am growing more convinced that under the
current language rules, having an additional tag argument which ties the
function to a namespace's semantics is the only good answer... but that's
another topic I guess.

> Also, there is the question of whether the above iterator interfaces
> should apply to both sparse and dense, or whether the dense iterators
> would just use the normal STL style iterators which would leave the
> indices out of the picture (for dense iterators they can be obtained in
> other ways).

I guess it depends how often you feel you can write an algorithm that works
well for both sparse and dense by using the index interface. My feeling is
that it is very useful during library development, because you can often use
common code to get something that works, although you may want to customize
it later for sparse/dense... and it's not unreasonable to think that a very
good compiler will not make you pay for such an interface to dense
iterators. On the other hand, it does make the iterator twice as big, so
it's not unreasonable to imagine that you will pay something for it.

I think the best efficiency is available with two iterator interfaces: one
which allows indexing, the other which doesn't. This would have benefits
even for some sparse codes: when you have the result structure
pre-calculated, you don't need to look at the indices.

-Dave