[macstl-dev] Proposal for mixed complex and real arithmetic
Glen Low
glen.low at pixelglow.com
Fri Jul 15 20:57:46 WST 2005
Hi Ilya, All
You offered about 1.5 months ago to do an extension of complex
arithmetic in macstl. If you're still willing and have the time to do
it, we'd welcome as the first major non-Pixelglow extension of macstl
and and an important test of the extensibility of the fundamental
programming.
Brief outline of scope:
The following mixed arithmetic operations should be made possible,
where r is a valarray of real number (int, float, double etc.) and c
is the complex equivalent (std::complex <int>, stdext::complex
<float>, stdext::complex <double>). Then,
r + c -> c
c + r -> c
r - c -> c
c - r -> c
r * c -> c
c * r -> c
r / c -> c
c/ r -> c
E.g. valarray <float> + valarray <complex <float> > should yield an
expression that can be treated as a valarray <complex <float> >.
Only valarrays of float and valarrays of complex float as the above
will be optimized using Altivec.
Things to do:
Based on macstl 0.3 (which has new differently-typed argument
functionality to support the above), here are the changes to be done:
A. [EASY] functional.h needs to have the arithmetic functors
specialized to accept the above combinations. Later we may consider
removing this in favor of a generalized functor that works with any 2
different types, but this would mean we'd need moderately complicated
typeof simulation to figure out the result type. Once A is done, you
should then be able to compile the expressions above and run them,
but without optimization.
B. [MODERATE] valarray_altivec.h needs to have a chunker
specialization defined on the right sort of expression, so that it
inserts const_chunk_iterator and chunk_begin for the optimization.
See valarray_altivec.h:251 etc. for hints. Once you do this, but
defining the body as empty you can detect whether the optimization
would be called -- e.g. by putting in a simple destructor with a
std::cout << "hi I'm here" message and compiling and running the
stage A.
C. [DIFFICULT] We need to define a sensible const_chunk_iterator
for the above. Ideally it should be generalizable for all complex/
real or real/complex combinations above, and passed in a template
template function which is the required operation -- see
valarray_function.h:529 for a hint. Ideally it should also be random
access when its two sub-iterators are random access too, but we may
have to check code generation to see if a forward iterator makes more
sense. This iterator should yield a vec <complex <float>, 2> and so
its complex subiterator is incremented whenever it is incremented,
but its real subiterator is incremented every other time. Presumably
an high/low indicator will be held in the iterator so that it knows
which 2 parts of the real subiterator needs to accessed, and an
appropriate lvsl/lvsr/vperm applied. Finally the operator* and
operator[] should implement the operation -- you might get away with
defining it in terms of the (real, real) function.
If it's too difficult to pull off C in one go, we can define "left is
real", "right is real" variants first, before seeing whether merging
the two into a single template is possible at all.
Note that this iterator cannot just be a specialization of the
existing binary_iterator, since the latter depends on the binary
operation being defined on vec <float> and vec <complex <float> >,
which of course won't work because it ignores the high/low issue.
Does that make sense? Would you have an idea of when it can be
achieved? Any questions or comments from any one will be welcome?
The further development of this would create things like arg (c) -> r
etc.
Cheers, Glen Low
---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen
More information about the macstl-dev
mailing list