From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-06-12 16:43:33
Paris (U.E.), le 12/06/2001
--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> Hi Hubert,
> I think your post could benefit from some explanation:
> ----- Original Message -----
> From: "Hubert HOLIN" <Hubert.Holin_at_B...>
> > I would just like to say at this point that higher-dimentional
> > 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"?
No, I meant to emphasize and linebreaks got in the way...
> 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?
I'll clarify a few things in just a moment, but what I meant
here (and badly messed-up) is that I had a three-indices thing A such
that for any index r in the range A[.][.][r] can be considered the
matrix of some linear operator, but that it turned out to be
advantageous to consider for some indices p and q the vector
> > 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
I once wrote some n-dimentional fft code (with extensions)
that I might dust up if someone's interested (it would require some
work to be more than just acceptable, IIRC). These things require
multi-dimensional objects. I wrote this in the context of chromatic
tinkering (for the pre-press sector) where I needed stacks of 4-d
objects, but it of course has uses in physics (pure and applied) in
this case 3-d is a must.
> > Quadtrees and higher-dimentional 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.
The "clarification" bit. I tend to see three layers of
multi-dimentional arrays (storage)
valarrays (storage with some efficient if limited agebra)
matrices & tensors & co (rich algebra)
It is often convenient to visualise matrices as storage, if
only to humor mathematical habit. Some object may at the begining of
some processing be endowed with algebraic meaning, but during the
processing be seen as storage (do do some index dance for instance),
and to reemerge as something with algebraic meaning. Valarray are stuck
in the middle, when the processing has some limited algebra than can be
The three examples I gave (simple n-d object indexing, fft
index dance and quadtree & co indexing) represent three types of
indexing problems I have actually encountered in my work.
Given this back-and-forth between representations and these
indexing problems, I believe iterators for matrices and co can't avoid
(or should idealy encompass) sophisticated behaviour.
> 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.
I currently use valarrays as (potentially hardware-
accelerated) mathematical vectors (as opposed to STL vectors), or,
sometimes, higher-dimensional objects with rather interesting indexing.
They work well IMHO.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk