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