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
