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

[Ingo Schmid]

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