Hi Ed, Ingo,
On Sat, Feb 20, 2021 at 01:39:51PM +0000, 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.)
>
> 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-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net><mailto: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.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-de...@lists.sourceforge.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:pdl-de...@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
>
>
>
>
> _______________________________________________
>
> pdl-devel mailing list
>
> pdl-de...@lists.sourceforge.net<mailto:pdl-de...@lists.sourceforge.net>
>
> https://lists.sourceforge.net/lists/listinfo/pdl-devel
>
> _______________________________________________
> 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
