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

[Ilya Lipovsky]

Glen,

I will work on it.

-Ilya

MacSTL wrote:

> 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
>
>