Re: matrix and vector iterators

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-06-13 10:32:41

Somewhere in the E.U., le 13/06/2001

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> 
> ----- Original Message -----
> From: "Hubert HOLIN" <Hubert.Holin_at_B...>

[SNIP]

> > > > 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.
> 
> I'm very interested. It's one of the things we'll be needing for our work
> here.

                OK, I'll dig it up. In the mean time you might be interested 
in FFTW (http://www.fftw.org/) against which I ave not tested my 
implementation but which should be good for most applications (in C).

> > > > 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.
> 
> I would still like to know the answer...

                I believe that, yes, we are still in the same problem domain. 
I see this as traversing in different ways an object which can be 
viewed at times as storage, at times as an algebraic object.

> > > > 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)
> 
> Are you familiar with MTL, the MTL3 prototype, and the linear algebra
> concepts being generated by Andy & Jeremy? This appears to be the same
> direction they're headed in.

                No, but I know I should... I will definitely have to take the 
time.

> > 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.
> 
> I would prefer to see sophisticated operations taking iterator parameters
> (possibly among others) as available, rather than building sophisticated
> behavior into the iterators themselves.

                One (among many) ways to see things is to remember that the 
mathematical definition of a matrix is a function (not the 
representation of some linear or bilinear operator, that comes as a 
fringe benefit, but as a function from some subset of NxN (or greater) 
to whatever set we are considering for values). An iterator is, 
basicaly, some form of bijection from a subset of N into the set of 
indices we are interested in. A 'behaviour' is then simply some 
function from the set of indices to itself. So what I am after can be 
seen as some form of an iterator adaptor, and can be a separate layer 
from the iterator; I just would like it to be there (and to be able to 
provide my problem-specific variation easily).

> > 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.
> 
> OK; I have no objection to interfaces which make valarrays usable, but I
> worry about carefully tailoring the library to use them.
> 
> -Dave

                They also are usefull "internally". For the final version of 
my quaternions and octonions I found practical to use them, but they 
are just some implementation detail, they are invisible to the user.

                        Hubert Holin
                        Hubert.Holin_at_[hidden]