Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
Craig, to add to that: asin(2) by itself has changed behaviour. pdl(‘NaN’) already exists as an easy way to get a NaN. The tests don’t have any checks on that behaviour. asin(2) really isn’t “not a number” – it’s only that the older libraries couldn’t correctly calculate/handle it. Therefore, how important is back-compat here? Also, this does raise the question of conversion of native complex values to real; now, it just drops the imaginary part. Is that correct? Should it instead always be NaN? Should it be NaN only if it has an imaginary part? The back-compat way would be that it should always be NaN, but that seems a pity. Discussion of this will inform what to make the tests enforce, since unfortunately they are currently silent. Best regards, Ed From: Ed .<mailto:ej...@hotmail.com> Sent: 21 February 2021 09:54 To: Craig DeForest<mailto:defor...@boulder.swri.edu> Cc: Luis Mochan<mailto:moc...@icf.unam.mx>; pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@lists.sourceforge.net> Subject: RE: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN Craig, would you agree that’s more of an argument for a nan() function to make a NaN? How much effort would it be to update that code? In any case, if the code only uses real types, it will operate exactly the same as it does now. From: Craig DeForest<mailto:defor...@boulder.swri.edu> Sent: 21 February 2021 02:08 To: Ed .<mailto:ej...@hotmail.com> Cc: Luis Mochan<mailto:moc...@icf.unam.mx>; pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN I have a lot of old code that uses asin(2) to make a NaN. (Hate to admit it, but there it is... ). This may break a lot of it. Sent from my iPhone On Feb 19, 2021, at 6:20 PM, 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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@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 +, Ed . wrote: > > Is this the expected behavior? > > I’d have to say yes – the changes made by Ingo are to use ’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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; > perldl<mailto:pdl-general@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.0004+1.7319121124709863e-16i > > Seems good, but > > pdl> p sqrt(-1) > Runtime error: Can't take sqrt
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
Craig, would you agree that’s more of an argument for a nan() function to make a NaN? How much effort would it be to update that code? In any case, if the code only uses real types, it will operate exactly the same as it does now. From: Craig DeForest<mailto:defor...@boulder.swri.edu> Sent: 21 February 2021 02:08 To: Ed .<mailto:ej...@hotmail.com> Cc: Luis Mochan<mailto:moc...@icf.unam.mx>; pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN I have a lot of old code that uses asin(2) to make a NaN. (Hate to admit it, but there it is... ). This may break a lot of it. Sent from my iPhone On Feb 19, 2021, at 6:20 PM, 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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@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 +, Ed . wrote: > > Is this the expected behavior? > > I’d have to say yes – the changes made by Ingo are to use ’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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; > perldl<mailto:pdl-general@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.0004+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 +, 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! > > > > > &
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
I have a lot of old code that uses asin(2) to make a NaN. (Hate to admit it, but there it is... ). This may break a lot of it. Sent from my iPhone > On Feb 19, 2021, at 6:20 PM, 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 > Sent: 20 February 2021 01:08 > To: pdl-de...@lists.sourceforge.net; perldl > 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 +, Ed . wrote: > > > Is this the expected behavior? > > > > I’d have to say yes – the changes made by Ingo are to use ’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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; > > perldl<mailto:pdl-general@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.0004+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 +, 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 > > > > > > > > > > ___
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
You’re most welcome! I will be incorporating that text into the docs as soon as I’ve finished sorting out a few gremlins I’ve found, and the FreeBSD thing. Thank you for the excellent questions, that’ll make the doc much better. On the FreeBSD point, it seems that up to 9.3 (from 2011) its libm didn’t implement csin etc (https://www.freebsd.org/cgi/man.cgi?query=complex=0=0=FreeBSD+9.3-RELEASE=default=html), but it did from version 10 (https://www.freebsd.org/cgi/man.cgi?query=complex=0=0=FreeBSD+10.0-RELEASE=default=html). I’ll have to add some check_lib magic and simply not define or test those functions if they’re not there. Best regards, Ed From: Luis Mochan<mailto:moc...@icf.unam.mx> Sent: 20 February 2021 15:41 To: pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net> Subject: Re: [Pdl-devel] PDL 2.026_01 released to CPAN Hi Ed, On Sat, Feb 20, 2021 at 03:12:44PM +, Ed . wrote: > Hi Luis, > > If you take a look at > https://metacpan.org/pod/release/ETJ/PDL-2.026_01/GENERATED/PDL/Ops.pm#ci > you’ll see there’s now... Thanks for the pointers and the explanations! Regards, Luis -- 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-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
Hi Ed, On Sat, Feb 20, 2021 at 03:12:44PM +, Ed . wrote: > Hi Luis, > > If you take a look at > https://metacpan.org/pod/release/ETJ/PDL-2.026_01/GENERATED/PDL/Ops.pm#ci > you’ll see there’s now... Thanks for the pointers and the explanations! Regards, Luis -- 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-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
Hi Luis,
If you take a look at
https://metacpan.org/pod/release/ETJ/PDL-2.026_01/GENERATED/PDL/Ops.pm#ci
you’ll see there’s now, from PDL::Ops, ci (which returns “i” in native format),
and you can get the real and imaginary parts with creal and cimag (documented
just below ci).
On your point of compatibility, with the latest PDL:
pdl> p asin(double(3))
NaN
pdl> p asin(cdouble(3))
1.5707963267948966+1.7627471740390861i
The MetaCPAN site is very good, and I’d humbly suggest it’s easier to take a
quick look there (or at the GitHub repo, the “native complex” stuff is a single
commit) than it is to email – however, clearly when this stuff gets shaken
out a bit more, and released properly, it will need improved docs, and a
clearer announcement!
pdl> p cdouble(2, 5, ci)
[2+0i 5+0i 0+1i]
pdl> p zeroes(cdouble, 5)
[0+0i 0+0i 0+0i 0+0i 0+0i]
pdl> p sequence(cdouble,3)
[0+0i 1+0i 2+0i]
Yes, it will be a 1-D array, which is more idiomatic. There’s still a slight
surprise, which I need to fix:
pdl> p cdouble("3 + 2i")
PDL::Core::new_pdl_from_string: found disallowed character(s) 'i' in 3 + 2i
However it’s easy to construct and also split up a single new-style complex
value (Ingo’s done a really good job):
pdl> $x = cdouble(3 + 2*ci)
pdl> p $x
3+2i
pdl> p creal($x)
3
pdl> p cimag($x)
2
Best regards,
Ed
From: Luis Mochan<mailto:moc...@icf.unam.mx>
Sent: 20 February 2021 14:48
To: pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>;
pdl-general@lists.sourceforge.net<mailto:pdl-general@lists.sourceforge.net>
Subject: Re: [Pdl-devel] PDL 2.026_01 released to CPAN
Hi Ed, Ingo,
On Sat, Feb 20, 2021 at 01:39:51PM +, Ed . wrote:
> Hi Ingo,
> ...
> 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
I have no clear idea about what should be expected from asin(3), but
shouldn't it be the same as from asin(pdl(3))?
I like the idea that $a=cdouble(sequence(3)) or $a=sequence(cdouble,3)
generate a [3] 1D array of CDouble instead of a [2,3] 2D array of doubles
interpreted as complex. It will help simplify my programs using complex
numbers. However, I don't know how to set a non-zero
imaginary part. I trield the constant i, but it is not defined. I
loaded the PDL::Complex module, but it contains the old style complex
numbers, where i is a PDL::Complex:
pdl> $ii=i
pdl> p $ii->info
PDL::Complex: Double D [2]
I also don't know how to take the real and imaginary parts of a new
style complex (the old 're' and 'im' don't work) or how to convert
from a complex to an array of reals (the old 'real' doesn't work
either). Is there some documentation already? (I haven't looked at the
new code yet).
Best regards,
Luis
>
> 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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>;
> pdl-general@lists.sourceforge.net<mailto:pdl-general@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 co
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
Hi Ed, Ingo, On Sat, Feb 20, 2021 at 01:39:51PM +, Ed . wrote: > Hi Ingo, > ... > 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 I have no clear idea about what should be expected from asin(3), but shouldn't it be the same as from asin(pdl(3))? I like the idea that $a=cdouble(sequence(3)) or $a=sequence(cdouble,3) generate a [3] 1D array of CDouble instead of a [2,3] 2D array of doubles interpreted as complex. It will help simplify my programs using complex numbers. However, I don't know how to set a non-zero imaginary part. I trield the constant i, but it is not defined. I loaded the PDL::Complex module, but it contains the old style complex numbers, where i is a PDL::Complex: pdl> $ii=i pdl> p $ii->info PDL::Complex: Double D [2] I also don't know how to take the real and imaginary parts of a new style complex (the old 're' and 'im' don't work) or how to convert from a complex to an array of reals (the old 'real' doesn't work either). Is there some documentation already? (I haven't looked at the new code yet). Best regards, Luis > > 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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; > pdl-general@lists.sourceforge.net<mailto:pdl-general@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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; > perldl<mailto:pdl-general@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.)
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; pdl-general@lists.sourceforge.net<mailto:pdl-general@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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@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, Lu
Re: [Pdl-general] [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-de...@lists.sourceforge.net > <mailto:pdl-de...@lists.sourceforge.net>; perldl > <mailto:pdl-general@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 +, Ed . wrote: > > > Is this the expected behavior? > > > > I’d have to say yes – the changes made by Ingo are to use > ’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 <mailto:moc...@icf.unam.mx>> > > Sent: 20 February 2021 00:09 > > To: > pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; > perldl<mailto:pdl-general@lists.sourceforge.net > <mailto:pdl-general@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.0004+1.7319121124709863e-16i > > > > Seems good, but > > > > pdl> p sqrt(-1) > > R
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
> Is this the expected behavior? I’d have to say yes – the changes made by Ingo are to use ’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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>; perldl<mailto:pdl-general@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.0004+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 +, 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-de...@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-de...@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-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel ___ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] [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.0004+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 +, 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-de...@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-de...@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-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
Re: [Pdl-general] [Pdl-devel] PDL 2.026_01 released to CPAN
This is good news! Thanks! Luis On Fri, Feb 19, 2021 at 08:15:59PM +, 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-de...@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-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
