[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=15987584#comment-15987584
]
Wilhelm Burger commented on MATH-1397:
--
Hello Eric,
thanks for this update. I have used Eclipse for all my projects over many years
with good success. However, I agree that Maven support is brittle, so I have
been considering to switch to IntelliJ as an alternative for quite a while now.
As a first test, I tried it on the 'commons-number' project and it importet
without any glitch. Looks good!
Thanks for the invitation to participate in this project, I'll be happy to look
into it and see where I can help. Note however that, while I do have a CS
background, I am not a mathematician (hobbyist at best) ...
--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)
[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=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)
[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=15986956#comment-15986956
]
Wilhelm Burger commented on MATH-1397:
--
Thanks - no, I had looked in the wrong place at ["Source code repository
(current)" | http://git-wip-us.apache.org/repos/asf/commons-rng.git] and did
not realize the other menu entry further down.
I was able to clone and build the complete repo (with command-line mvn)
successfully. However, importing into Eclipse gave me a couple of errors
(apparently related to the maven-antrun-plugin and checkstyle) which I could
not resolve, e.g. (for every pom.xml on line 23):
{noformat}
Plugin execution not covered by lifecycle configuration:
org.apache.maven.plugins:maven-antrun-plugin:1.7:run (execution:
javadoc.resources, phase: generate-sources)
pom.xml /commons-numbers-complexline 23
{noformat}
Any hints appreciated...
> 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)
[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=15986728#comment-15986728
]
Gilles commented on MATH-1397:
--
Did you proceed as indicated
[here|http://commons.apache.org/proper/commons-numbers/source-repository.html]?
>From the top directory, running
{noformat}
mvn clean package
{noformat}
should create all the artefacts (to be found in each module's "target"
subdirectory).
> 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)
[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=15986684#comment-15986684
]
Wilhelm Burger commented on MATH-1397:
--
Hello Gilles, thanks for your enlightening comments. I'd be happy to help if I
can (i.e., add anything to the outstanding experts' work). I have seen the
recent patch for the pow() method by Raymond and wondered if there was an
accessible (and complete) GIT repo for the "Commons Numbers" project. I tried
to build the subproject but could not find the associated parent project (POM).
--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)
[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=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)
[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)
[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=15793695#comment-15793695
]
Gilles commented on MATH-1397:
--
Hello Mario and Raymond.
Having complex numbers (and related functionality) in their own component was
on the roadmap; an effort led by Eric Barnhill (to whom I've just assigned this
issue).
If you'd like to help move the code out of Commons Math, please post to the
"dev" ML.
Thanks for the report.
> 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
>
> ```
> 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.4#6332)
[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=15793135#comment-15793135
]
Raymond DeCampo commented on MATH-1397:
---
Added a pull request to implement the case of 0 raised to a real positive
number:
https://github.com/apache/commons-math/pull/47
> 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
>Priority: Minor
>
> ```
> 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.4#6332)
