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 sh
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
> 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
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)
Run
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.
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, mathematical
