Hi Ed,
> ...However, are you seeing a use for it that adds anything to simply using
> i2C from PDL::Complex?
No.
Best regards,
Luis
--
o
W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
Instituto de Cienci
Hi Luis,
ci() was introduced as part of the native-complex changes (obviously). It
should be considered temporary for now, since the current way forward I see is
to integrate PDL::Complex into the native stuff (since they actually appear to
be binary-compatible, as mentioned earlier), and there
Hello,
I'm intrigued by ci. What is the reason for its behavior?
I found that ci was defined through pp_def with one output argument.
Thus, ci+$x is interpreted as ci(+$x) which actually assigns
complex i to each element of $x if $x is a complex pdl. If $x is real,
then it assigns 0 (I guess it ty
Hi Luis,
Glad 2.028 seems work for you!
There’s no fundamental reason for PDL::FFTW3 not to update its dep to PDL
2.028, and then to use FFTW3’s complex stuff. It’s very interesting that the
page you’ve linked to says C99 complex types are binary-compatible with a
two-element array – that sugg
Hi Ed,
> The problem you identified is due to a logic error in the bifuncs in P::Ops –
> they weren’t handling complex inputs correctly because the code to do so was
> behind a check for unsigned-handling. Now that’s corrected, and there’s a
> test to guard against regressions. As soon as the
