Hi Ingo,

PDL now has updated CI (continuous integration) that checks every single push 
and PR compiles and passes tests on Ubuntu (with all optional things installed, 
and with various options like USENAN and PER_PDL on and off). Also on MacOS and 
Windows, with just the basic stuff (see other messages for problems with e.g. 
PGPLOT on MacOS). Yes, I fixed up the NaN stuff on all platforms.

There is a problem with the new code not running on at least Slaven’s FreeBSD 
9.2 boxes (as report by his automated smoker) as it can’t dyna-load csinf, even 
though the “-lm” is given in ::Ops’s Makefile.PL. I’m not yet able to get a 
FreeBSD 9 VM running to fix this. Ideas are welcome! While supporting older 
Perls is very much the Perl way, I’m in two minds about how far to go to 
support obsolete OSes (9.2 reach end-of-life (EOL) in 2014). What do others 
think?

If the general approach is to ensure all existing code carries on working 
as-is, then that’s fine. If people can report regressions (changes of 
behaviour) with a test-case, we can capture those in automated tests and fix 
them. Is a free-standing asin(3) returning a complex number considered bad? I 
just did a quick check, and calling asin() on piddles with a real type, and a 
complex type, each does the expected thing:

pdl> $x = pdl(cdouble, 3)

pdl> p asin($x)
1.5707963267948966+1.7627471740390861i
pdl> $x = pdl(double, 3)

pdl> p asin($x)
NaN

With regards to PP, I have in mind to go in and make it use more C macros (for 
shorter XS code which should help the compiler), and to fix up the #line stuff 
better for easier debugging and to help get the test-coverage reporting right, 
which it isn’t entirely at the moment. If you can tell me more about the issues 
with implicit casts, I can look at that while there!

Best regards,
Ed

From: Ingo Schmid<mailto:ingo...@gmx.at>
Sent: 20 February 2021 13:21
To: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>; 
pdl-gene...@lists.sourceforge.net<mailto:pdl-gene...@lists.sourceforge.net>
Subject: Re: [Pdl-devel] PDL 2.026_01 released to CPAN


Hi Ed,

thanks for picking this up! I am really really bad at housekeeping and with 
multi-developer git, I'm sorry for the mess I've left you to deal with. When I 
saw you released the new version, I was actually considering giving it a push. 
Now I am really grateful you beat me to it ! ;)

There was still the issue of build failure on windows with bad values and 
either use NaNs as bad on or off. Have you managed to root that out? I've run 
out of steam on this. It was really just one combination that caused the 
failure.

With regard to expected behaviour, that is difficult really, as there often is 
no general answer. I guess I would advise to be conservative so that existing 
real-valued code behaves as much the same way as it ever did. I figure that 
this  is probably quite difficult to do rigorously.

As some veteran developers for sure know is that there is an implicit promotion 
of types to double, which is still in place. I think it is somewhere hidden in 
PP, I think. Other parts of the code implicitly or explicitly rely on this, if 
I remember correctly. That leads to the odd cases when a function is not 
defined for complex numbers, the argument is cast to double (which is the real 
part) and then silently used in the function.

To the point, the desired behaviour of implicit casts is now even more relevant 
and has become non-trivial then it used to be so far. Anyone remembering the 
64-bit integer to double loss of precision discussion?

Best

Ingo
On 2/20/2021 2:20 AM, Ed . wrote:
For sqrt with real numbers, there's already multiple possible answers! So this 
is not adding any additional problems.

For log, it’s probably most pragmatic to have an additional function, which 
already exists in PDL::Complex. Question: does this new “native” complex 
support mean PDL::Complex should change / be simplified? Also, are you saying 
that you consider the behaviour of promoting floats/doubles into their complex 
counterparts is wrong?

Best regards,
Ed

From: Luis Mochan<mailto:moc...@icf.unam.mx>
Sent: 20 February 2021 01:08
To: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net>; 
perldl<mailto:pdl-gene...@lists.sourceforge.net>
Subject: Re: [Pdl-devel] PDL 2.026_01 released to CPAN


Hi Ed,

I'm not sure about what should be expected for operations on real
numbers that have no real answer: a complex answer or an error? (In the
case of sqrt(-1) or worse, for log(-1) there is the further problem of
multiple possible answers.)

Consider

pdl> $i=sequence(long,10);

pdl> p $i/3
[0 0 0 1 1 1 2 2 2 3]

pdl>

In this case, division is not promoting longs into floats. However
asin(3) does promote floats into complex. sqrt(-1) isn't. So I'm still
confused about what are the appropriate expectations. I'd follow your
suggestion if I were sure what to request.

Regards,
Luis


On Sat, Feb 20, 2021 at 12:52:58AM +0000, Ed . wrote:
> > Is this the expected behavior?
>
> I’d have to say yes – the changes made by Ingo are to use <complex.h>’s 
> native-ish C complex-numbers support, and PDL types and code changes to 
> support that. The change to asin’s behaviour came for free with that. It’s 
> not yet fully pervasive, and I’m not 100% sure whether the new complex 
> behaviour should actually change to be opt-in.
>
> On the other hand, making it do the mathematically correct thing all the way 
> seems like the correct way forward! If people can try their various scripts 
> and extensions and see if anything breaks, and/or find things that are not 
> according to their expectations, it would be really helpful to report that on 
> here. Luis, could you open an issue on the repo and capture at least this 
> sqrt point? (A PR to add a failing test would be even better, and a PR with a 
> failing test plus code to fix the problem would be better again 😊)
>
> Best regards,
> Ed
>
> From: Luis Mochan<mailto:moc...@icf.unam.mx>
> Sent: 20 February 2021 00:09
> To: 
> pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net><mailto:pdl-devel@lists.sourceforge.net><mailto:pdl-devel@lists.sourceforge.net>;
>  perldl<mailto:pdl-gene...@lists.sourceforge.net>
> Subject: Re: [Pdl-devel] PDL 2.026_01 released to CPAN
>
> I installed it 026_01 (from github/master)
>
>
> pdl> p asin(3)
> 1.5707963267948966+1.7627471740390861i
>
> pdl> p sin(asin(3))
> 3.0000000000000004+1.7319121124709863e-16i
>
> Seems good, but
>
> pdl> p sqrt(-1)
> Runtime error: Can't take sqrt of -1 at (eval 400) line 5.
>
> pdl> use PDL::Complex
>
> pdl> p sqrt(-1)
> Runtime error: Can't take sqrt of -1 at (eval 416) line 5.
>
> pdl> p sqrt(-1+0*i)
> 0 +1i
>
> pdl>
>
> Is this the expected behavior?
>
> Regards,
> Luis
>
>
>
> On Fri, Feb 19, 2021 at 05:52:44PM -0600, Luis Mochan wrote:
> > This is good news!
> > Thanks!
> > Luis
> >
> > On Fri, Feb 19, 2021 at 08:15:59PM +0000, Ed . wrote:
> > > Dear PDL users,
> > >
> > > I’ve just uploaded PDL 2.026_01 to CPAN. It has Ingo Schmid’s “native 
> > > complex types” code (as tidied up a bit). Please give it a go and report 
> > > whether it works! Please note that now e.g. asin(3) will not return NaN, 
> > > but instead a complex number (which is, of course, mathematically valid).
> > >
> > > As Derek said, please report any issues you find to the mailing list 
> > > (good), or create an issue (better) or a pull request (best!) on GitHub.  
> > > Thanks, and Happy PDL-ing!
> > >
> > > Best regards,
> > > Ed
> >
> >
> > > _______________________________________________
> > > pdl-devel mailing list
> > > pdl-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:pdl-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pdl-devel





_______________________________________________

pdl-devel mailing list

pdl-devel@lists.sourceforge.net<mailto: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

Reply via email to