Schmid<mailto:ingo...@gmx.at>
Sent: 08 March 2021 16:58
To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net>
Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.027 released
Hi Ed,
I think that the first point of reference for data types should PDL::Types, no?
I
ceforge.net<mailto:pdl-general@lists.sourceforge.net>
Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.027 released
On Mon, Mar 08, 2021 at 03:28:09PM +, Ed . wrote:
> Hi folks,
>
> I added the warning because I found the behaviour surprising when adding
> tests. My plan now is
t the PDL::Complex
integration.
Best regards,
Ed
*From: *Luis Mochan <mailto:moc...@icf.unam.mx>
*Sent: *08 March 2021 15:15
*To: *pdl-general@lists.sourceforge.net
<mailto:pdl-general@lists.sourceforge.net>
*Subject: *Re: [Pdl-general] [Pdl-devel] PDL 2.027 released
Hi Ingo,
On Mon
On Mon, Mar 08, 2021 at 03:28:09PM +, Ed . wrote:
> Hi folks,
>
> I added the warning because I found the behaviour surprising when adding
> tests. My plan now is that ci() will go away, so my proposal is to use it as
> “ci()” for now, bearing in mind it’s only temporary. How does that sound?
moc...@icf.unam.mx>
Sent: 08 March 2021 15:15
To: pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net>
Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.027 released
Hi Ingo,
On Mon, Mar 08, 2021 at 03:35:36PM +0100, Ingo Schmid wrote:
> ...
> Now, looking into PDL::Ops
Hi Ingo,
On Mon, Mar 08, 2021 at 03:35:36PM +0100, Ingo Schmid wrote:
> ...
> Now, looking into PDL::Ops you will see this warning:
>
> Returns the complex number 0 + 1i.
>
> B because this is not defined as a constant (with empty
> prototype), you must use it either as C<10*ci> or C. If you
>
Hi Luis,
thank you for demonstrating. I remember now that for some reason ci
required explicit parentheses. It is one of the PP mysteries, i.e., my
lack of deep knowledge, I think.
Now, looking into PDL::Ops you will see this warning:
Returns the complex number 0 + 1i.
B because this is not d
Hi Ingo,
On Mon, Mar 08, 2021 at 09:49:06AM +0100, Ingo Schmid wrote:
> ...
> is it not doing ci() + $x (expected behaviour) rather than ci( +$x) ?
No. For example:
$ pdl2
...
pdl> $x=1+0*ci # initialize a complex variable with a real value
pdl> p $x
1+0i
pdl> p ci()+$x #
Hi Luis,
is it not doing ci() + $x (expected behaviour) rather than ci( +$x) ?
Ingo
On 07.03.21 23:42, Luis Mochan wrote:
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 type-conv
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
Hi Luis,
Thanks for the great problem-finding and -tracking!
The difference between “pow” and “power” is that the latter is more
sophisticated, and PDL-ish, and allows for mutations (such as with overloaded
operators). The former is just the PDL-ised version of the “-lm” function. For
sure, we
Well, so far, I have found that ** invokes the function PDL::power
which seems not to work with the new complex types. I don't know the
reason for having both a 'pow' and a 'power' function.
On the other hand, would it be feasible to enable data flow back to
the real and imaginary parts of a new
And pow also works. So it seems the problem is related to the
translation from the binary operator version '**'.
pdl> p +(1+ci)->ipow(2)
0+2i
pdl> p +(1+ci)->pow(2)
1.2246467991473532e-16+2i
pdl> p +(1+ci)**2
1+0i
pdl>
On Sat, Mar 06, 2021 at 05:03:49PM -0600, Luis Mochan wrote:
> > So powers of
> So powers of complex numbers are not working. I haven't looked yet at
> the P::Ops code. I'll try later.
ipow does work though.
--
o
W. Luis Mochán, | tel:(52)(777)329-1734 /<(*)
Instituto de Ciencias F
Hi,
On Sat, Mar 06, 2021 at 07:41:18PM +, Ed . wrote:
> Dear PDL folks,
> I have just uploaded PDL 2.027. Changes from 2.026:
Great!
I want to start using the new complex code, mostly to avoid the errors
due to bad uses of the extra (real-imag) dimension.
> - native support for complex num
19 matches
Mail list logo
