commons-issues mailing list archives

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

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

Gilles commented on MATH-1397:
------------------------------

bq. status of this issue

It has been fixed in the new ["Commons Numbers" project|http://commons.apache.org/proper/commons-numbers]
(see NUMBERS-4).
The {{complex}} package will not be part of the next release of Commons Math.

bq. I told my students to use a "proven" library

I totally agree.

bq. first thing they run across is this bug.

I'm very sorry.
It shows that even after many years, there is still room for improving supposedly mature code.

bq.  What should I tell them now?

Please tell them that they are most welcome to test and review the code, to provide comments
and suggestions, and participate in the development by filing bug reports and fixing bugs.

"Commons Numbers" is being actively worked on right now.
I hope that we are able to produce the first official release in the coming weeks.

The new (non-official) artefacts for the "complex" functionality can downloaded from the [snapshot
repository|https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/].

bq. I do not know of any other environment with a similar behaviour.

You are quite right.
Eric Barnhill is leading the refactoring, with the explicit goal to make the behaviour conform
to the ISO standard.
I'm sure that he'll welcome your help. If not done already, please subscribe to the "dev"
ML in order to discuss the features which you expect from an implementation of the concept
of "complex numbers".

bq. Wouldn't it be simpler to perform exponentiation in polar form

I certainly agree.
I had a, perhaps naive, proposal aimed at ensuring that the most effective algorithm would
be used for a given computation: see https://issues.apache.org/jira/browse/NUMBERS-10
Please let us know what you think.

> 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