The problem with that is in “treated as” – remember that native complex numbers
are an area of memory very closely resembling two floating-point numbers of
whatever precision. There is no way to persuade the computer to “treat” an area
of memory which is only one floating-point number as that.
Hi Ingo,
[adding a “real” type qualifier]
> How do you do that? I tried to implement this and failed because I didn't
> know where to start. ;)
Looking in PP.pod gives a good start. In this case, it’s related to Pars, which
are encapsulated in PdlParObj. After that, it was easy! (Apart from
Luis, use cdouble or cfloat for that.
If you want to preserve the floating point precision, this is harder. I
think a function should be introduced to do exactly this. complex() in
PDL::Complex ?
Ingo
On 26.03.21 06:29, Luis Mochan wrote:
I started playing with the new complex numbers. I find
do the same. Even conj kind of works that way.
Best regards,
Ed
*From: *Luis Mochan <mailto:moc...@icf.unam.mx>
*Sent: *26 March 2021 05:30
*To: *pdl-devel@lists.sourceforge.net
<mailto:pdl-devel@lists.sourceforge.net>
*Subject: *Re: [Pdl-devel] [Pdl-general] PDL 2.029 released
I
mag on real data? It
seems to me that too should throw an exception.
Best regards,
Ed
From: Luis Mochan<mailto:moc...@icf.unam.mx>
Sent: 26 March 2021 05:30
To: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>
Subject: Re: [Pdl-devel] [Pdl-general] PDL 2.
I started playing with the new complex numbers. I find it nice
and useful that creal and cimag can be applied to real pdl's, but the
results are promoted to complex:
pdl> $x=pdl(1)
pdl> p $x
1
pdl> p $x->creal
1+0i
pdl> p $x->cimag
0+0i
Equality and inequality comparisons do work but they also
Hi,
I also noticed that complex comparisons don't throw errors but compare
the real part. I must say, I don't like the behaviour, although I did
not catch it.
At the bottom of this, I think, is the implicit type conversion. When an
operation is not defined for a given type, pdl implicitly
So, I figured the code bit ($TCG), but have no elegant solution ready.
There's no macro to match a complex' and real basic type, no? Ingo
Ingo
On 15.03.21 12:01, Ingo Schmid wrote:
Hi Ed,
creal, etc. including carg, do not cast onto their real-valued counter
part. I think they should, no?
Hi Ed,
creal, etc. including carg, do not cast onto their real-valued counter
part. I think they should, no?
pdl> p $x
1+1i
pdl> p abs $x
1.41421354+0i
pdl> p creal $x
1+0i
pdl> p cimag $x
1+0i
pdl> p carg $y
0.78539816339744828+0i
That leaves conj (complex conjugate) which should return a
