You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Wilhelm Burger (JIRA)" <ji...@apache.org> on 2017/04/27 07:15:04 UTC

[jira] [Commented] (MATH-1397) Complex.ZERO.pow(2.0) is NaN

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

Wilhelm Burger commented on MATH-1397:
--------------------------------------

I am not sure what the status of this issue is (apparently has been unsolved for years), but this is an URGENT PROBLEM and should be fixed soon!

I told my students to use a "proven" libary instread of doing their own implementation of 'Complex' and the first thing they run across is this bug. What should I tell them now? Surprisingly, the (NaN, NaN) outcome is intended (even checked in a test case!), although I do not know of any other environment with a similar behaviour.

Why is the pow() based on the log() in the first place? Wouldn't it be simpler to perform exponentiation in polar form, without the 0-singularity?

--Wilhelm

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