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
