Luis,
On 22.05.19 04:31, Luis Mochan wrote:
Dear Ingo,
On Wed, May 22, 2019 at 02:15:24AM +0200, Albrecht Ingo Schmid wrote:
Dear all,
I've been working on native complex number support and got it to the
stage of passing all tests on my linux box. Each element of a piddle is
a complex number, no more hassle whether the first dimension needs to be
two or not. Essentially it adds binding to C's complex.h.
This is great news!
pdl> $a=sequence(5)+ci()*sequence(5)*2
pdl> p $a
[0+0i 1+2i 2+4i 3+6i 4+8i]
pdl> p $a->info
PDL: CDouble D [5]
pdl>
looks great (a 5 element 1-D complex pdl)
instead of the previous version
pdl> use PDL::Complex
pdl> $b=sequence(5)+i*sequence(5)*2
pdl> p $b
[0 +0i 1 +2i 2 +4i 3 +6i 4 +8i]
pdl> p $b->info
PDL::Complex: Double D [2,5]
pdl>
which is a PDL::Complex (which some routines, such as those in FFTW3
don't understand as a PDL) and is a 2x5 2 dimensional array. This has produced
some confusion (for example, reductions on these complex arrays should
iterate on the second, not the first index).
Especially the fact that it's not a PDL derived class is important,
deriving from PDL itself is tedious enough without this extra layer of
complexity (no pun intended).
Check out the nat_c2 branch here, all others are irrelevant and should
be deleted:
https://github.com/fantasma13/pdl
Use cdouble, cfloat, ci() (imaginary unit), cimag, creal, abs, carg to
convert. Most basic functions should work as expected from complex math,
please report any odd behaviour.
The FFT module should play along. I'd love to see the same for FFTW3.
Currently, FFTW3 works on 2xN real PDL's which could be obtained from
a PDL::Complex value using the function 'real', as in
$c=sequence(2,5)->complex, $r=$c->real. This could then be fed to
the FFTW3 routines. Are there conversions between the new complex
N-pdl's and real 2xN pdl's? Or should one take real and imaginary parts
and them somehow join them?
At the moment, cat (creal($x),cimag($x))->mv(-1,0) should do the trick.
I intend to update the module with these kind of wrappers (see fft.pd)
once this update gets released.
Just experimenting I tried combining the two kinds of complex numbers
with funny results
pdl> p $a
[0+0i 1+2i 2+4i 3+6i 4+8i]
pdl> p $b
[0 +0i 1 +2i 2 +4i 3 +6i 4 +8i]
pdl> p $a+$b
[0+0i +0+0ii 2+2i +2+0ii 4+4i +4+0ii 6+6i +6+0ii 8+8i +8+0ii]
pdl> p $a->info
PDL: CDouble D [5]
pdl> p $b->info
PDL::Complex: Double D [2,5]
pdl> p +($a+$b)->info
PDL::Complex: CDouble D [2,5]
with a PDL::Complex that takes a complex double for real part and
another for imaginary part (with funny double 'ii's). I guess that the
two kinds don't mix.
No, they don't mix and are not intended to. It's simple enough to
convert. Use complex(creal($x),cimag($x)) or
real($x(0,))+real($x(1,))*ci in the other direction. I didn't check the
syntax, this is from memory and may not work literally, but you get the
gist.
I wonder why you need the parenthesis in ci()? The old imaginary unit
i doesn't needs them.
pdl> $a=sequence(5)+ci()*sequence(5)*2
pdl> p $a
[0+0i 1+2i 2+4i 3+6i 4+8i]
pdl> $a=sequence(5)+ci*sequence(5)*2
syntax error at (eval 120) line 4, near "*sequence("
pdl> $b=sequence(5)+i*sequence(5)*2
pdl> p $b
[0 +0i 1 +2i 2 +4i 3 +6i 4 +8i]
though
pdl> $a=sequence(5)+sequence(5)*2*ci
with ci at the end without parenthesis does work.
I wonder about this myself. ci is just a function, after all. Has anyone
got a clue?
There are two general issues I've come across: Implicit type conversion
to the next datatype that allows a specific operation. I've seen two
examples while working on this:
...
Thanks for this welcome development!
Regads,
Luis
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
