
Boost : 
From: David Abrahams (abrahams_at_[hidden])
Date: 20010612 08:57:25
Hi Hubert,
I think your post could benefit from some explanation:
 Original Message 
From: "Hubert HOLIN" <Hubert.Holin_at_[hidden]>
> I would just like to say at this point that higherdimentional
> tensors whould gain from having a nice iterator interface.
What do you mean by "nice"?
> I had once cause to consider a "stack" of several usual matrices,
> for which it was advantageous to consider all elements of the same *
> last* index.
Sorry, is this multiplication? "same * last"?
Even if you just meant to emphasize "last", I don't understand what you mean
by "consider all elements of the same last index". Can you explain?
> Also, fft in more than 2 dimensions simultaneously (I also need
> that sometimes) could benefit from such tools (remember the index
> dance!).
Not understanding the first 2 statements, I find it hard to understand this
one.
> Quadtrees and higherdimentional analogues represent another form
> of indexing fun that should not be overlooked.
Aren't these really a completely separate application domain? We do not need
to invent a universal iteration interface.
> Finaly, valarray has (more or less) efficient traversal with
> strides and (hopefully) very efficient computational power, but next to
> no tensorial behaviour, whereas matrices (and tensors) could have good
> algebraic properties but currently lack good traversal.
What do you mean by "good"?
MTL has a strided_view, I think.
> It would be
> ideal to be able to go back and forth between the two concepts (TNT can
> build matrices and vectors upon valarrays, but the crawling of said
> seems to be slowing still, as if it were possible...), as far as
> possible anyway (sparse matrices may be out of luck).
A big problem with valarrays is that there are problems with their
specification, and there isn't even anyone on the C++ committee who
understands their original intent well enough to correct the problem. I am
/extremely/ wary of treading into valarray territory with our library for
that reason.
Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk