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...>
> > > > 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
> > > 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
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
> > > 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
> > > > 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
> > 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk