From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-13 19:34:08
----- Original Message -----
From: "Hubert HOLIN" <Hubert.Holin_at_[hidden]>
> > I'm very interested. It's one of the things we'll be needing for our
> > 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).
Yes, we know about that one, thanks.
> > > > > 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
> > 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.
I guess "quadtree" means something different to you than it does to me. I
thought it was a kind of spatial indexing system used often in 3-d graphics
> > I would prefer to see sophisticated operations taking iterator
> > (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).
That view corresponds well with the linear algebra concepts we've been
> An iterator is,
> basicaly, some form of bijection from a subset of N into the set of
> indices we are interested in.
I'm not sure if that part rings true. Maybe you should clarify a bit.
> A 'behaviour' is then simply some
> function from the set of indices to itself.
Maybe you should give an example of what you've got in mind.
> > 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.
I'm convinced about valarray, now. It's basically a likely way to access
optimizations which would otherwise require platform-specific code or
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk