The $T part is just the introduction; so $TGC(floatversion,doubleversion)... Similarly $TFD(floatv,doublev). It’s one way of dealing with the different types in a threadloop, with the other being “types(F) %{ ... %} types(D) %{ ... %}”.
I agree with your analysis of the new “cfunc” functions, see my separate note on my plan to deal with this! From: Ingo Schmid<mailto:ingo...@gmx.at> Sent: 15 March 2021 11:01 To: Ed .<mailto:ej...@hotmail.com>; pdl-devel<mailto:pdl-devel@lists.sourceforge.net> Subject: Re: [Pdl-general] PDL 2.029 released 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<mailto: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