[macstl-dev] Proposal for mixed complex and real arithmetic

[Glen Low]

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