commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Barnhill (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-1397) Complex.ZERO.pow(2.0) is NaN
Date Thu, 27 Apr 2017 16:42:04 GMT

    [ https://issues.apache.org/jira/browse/MATH-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986987#comment-15986987
] 

Eric Barnhill commented on MATH-1397:
-------------------------------------

Welcome Wilhelm!

I actually found it so fragile, to integrate Eclipse and Maven with a Git project, that I
gave up Eclipse and learned how to code Java using personalized Vim. I realize this is not
much of a hint.

I am currently working to conform Complex to the ISO C standard. If you know the standard
you know there are a great many behaviors to check, and Java only does some of them inherently,
so it has turned into a pretty large project. You should feel free to fix any behaviors you
don't like on your own branch and I will integrate them.

As for using the polar representation for certain operations, I certainly have no objection
in principle. The ISO standard is defined completely in terms of real and imaginary, including
a great many equivalence relationships that I need to test. Thinking about how to re-define
every branch cut in polar coordinates is more than I can commit to and would be prone to error.
Also, libraries that provide useful trig formulas like Complex.js provide them all in terms
of real and imaginary and reconstructing these in polar would also be prone to error.

 cpow() is covered in G.6.4.1 and actually has no branch cuts so you should go ahead; however
you can see from G.6.3.2 that we could not do clog() the same way.


> Complex.ZERO.pow(2.0) is NaN
> ----------------------------
>
>                 Key: MATH-1397
>                 URL: https://issues.apache.org/jira/browse/MATH-1397
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 3.6.1
>         Environment: Linux, Java1.7/Java1.8
>            Reporter: Mario Wenzel
>            Assignee: Eric Barnhill
>            Priority: Minor
>             Fix For: 4.0
>
>
> ```
> package complextest;
> import org.apache.commons.math3.complex.Complex;
> public class T {
> 	public static void main(String[] args) {
> 		System.out.println(Complex.ZERO.pow(2.0));
> 	}
> }
> ```
> This is the code and the readout is `(NaN, NaN)`. This surely isn't right. For one, it
should actually be zero (https://www.wolframalpha.com/input/?i=(0%2B0i)%5E2) and second of
all, the documentation doesn't state that anything could go wrong from a Complex number that
has no NaNs and Infs.
> The other definition states that it doesn't work when the base is Zero, but it surely
should. This strange corner case destroys any naive implementation of stuff wrt the mandelbrot
set.
> It would be nice to not have to implement this exception myself.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message