Re: [Pdl-devel] [Pdl-general] PDL 2.029 released

Ingo Schmid Mon, 29 Mar 2021 03:10:32 -0700

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 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 return
complex values:

pdl> p $x==1
1
pdl> p $x->creal==1
1+0i
pdl> p $x->creal==2
0+0i
pdl> p $x->creal!=2
1+0i

This is troublesome, as their boolean interpretation is not correct:

pdl> print +($x->creal==1)?'yes':'no'
yes
pdl> print +($x->creal==2)?'yes':'no'
yes
pdl> print +($x==2)?'yes':'no'
no

On the other hand, greater than, lower than, etc. do compare the real
parts only and return a real value.

pdl> $y=ci
pdl> p $y<1
1
pdl> p $y<ci
0
pdl> p $y<=0.01*ci
1

Regards,
Luis






On Mon, Mar 15, 2021 at 04:00:13PM +0100, Ingo Schmid wrote:

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 converts (to
double) until it can do it.

This is useful in may situations, but in others not. This breaks, of
course, some of the symmetry in ops.pd (maybe primitive and ufunc,
amongst others). Especially biops would need revisions.

I think this is a fundamental design decision. Whatever is established
now will have impact. I tried to raise awareness to this in the other
thread.

Ingo

On 15.03.21 13:56, Ingo Schmid wrote:

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?

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 complex
number.

I think these are all.

I think you introduced cfunc in ops.pd with a codestring that's
beyound me. 😁 Where does  $TCG come from? I assume it means handling
types C and G, I don't get the T, at the moment.

Let me know what you think.

Best

Ingo

On 12.03.21 19:25, Ed . wrote:

Dear PDL folks,

PDL 2.029 has just been released. Following Monday’s dev-release,
the CPAN Testers results show no test failures at all, and only a
few build-failures which appear to be caused by an older
ExtUtils::F77 erroneously adding “-lquadmath” on a Windows platform
that didn’t have it.

This version’s only changes from 2.028 are to fix a few remaining
test failures for “native complex” numbers on platforms with buggy
libm, and to incorporate some material improvements made to PDLA.

The next steps will be to solidify the native complex support by
adding to PDL::Complex ways translate/have data flow between the two
ways of accessing the information. As an early approach I will be
enhancing PDL::FFTW3 to correctly support native complex numbers. I
still want to make PDL’s “from string” capability support “i” as a
value, but haven’t done so yet. Ingo, your updates (or even pointers
on doing so) to the PDL docs will be very helpful, I hope you’ll
find time to take a look :-)

After the above, the next stages will be to start “splitting the
iceberg” of PDL, starting by extracting a minimal (but not too
minimal) PDL::Core distribution, which I will be checking against
the main PDLPorters other PDL::* distros by making them depend on
only PDL::Core, and ensuring they still work. I am in two minds on
whether to have a true “PDL::Core” with a separate
“PDL::Interactive” which has a bit more (the interactive shells for
instance), but have the feeling that the interactive shells etc are
so small and minimal in terms of build that this would not help.
Anyone else have views?

Please try this version with all your code, and report problems with
PRs, GitHub issues, or at least email reports!

Best regards,

Ed



_______________________________________________
pdl-general mailing list
pdl-gene...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-general


_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel


_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel


--

                                                                   o
W. Luis Mochán,                      | tel:(52)(777)329-1734     /<(*)
Instituto de Ciencias Físicas, UNAM  | fax:(52)(777)317-5388     `>/   /\
Av. Universidad s/n CP 62210         |                           (*)/\/  \
Cuernavaca, Morelos, México          | moc...@fis.unam.mx   /\_/\__/
GPG: 791EB9EB, C949 3F81 6D9B 1191 9A16  C2DF 5F0A C52B 791E B9EB


_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel

Re: [Pdl-devel] [Pdl-general] PDL 2.029 released

Reply via email to