[
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)
