
Boost : 
From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 20010613 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 ndimentional 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
> > multidimensional objects. I wrote this in the context of chromatic
> > tinkering (for the prepress sector) where I needed stacks of 4d
> > objects, but it of course has uses in physics (pure and applied) in
> > this case 3d 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 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.
>
> 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:
> >
> > multidimentional 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 backandforth 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 problemspecific variation easily).
> > I currently use valarrays as (potentially hardware
> > accelerated) mathematical vectors (as opposed to STL vectors), or,
> > sometimes, higherdimensional 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]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk