[macstl-dev] Re: Proposal for mixed complex and real arithmetic
Ilya Lipovsky
lipovsky at skycomputers.com
Tue Jul 19 00:18:41 WST 2005
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
>
>
More information about the macstl-dev
mailing list