Re: matrix and vector iterators

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-06-12 16:43:33

Paris (U.E.), le 12/06/2001

        Hi!

--- 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 
A[p][q][.].

> > 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.

                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 
functionality:

        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 
hardware-accelerated.

                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.
> 
> -Dave

                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.

                        Hubert Holin
                        Hubert.Holin_at_[hidden]