commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
Date Thu, 20 Apr 2017 03:17:04 GMT

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

Bruno P. Kinoshita edited comment on MATH-1414 at 4/20/17 3:16 AM:
-------------------------------------------------------------------

Trying to make sure I understand the issue in the code.

Using -2.44242319E-315 as input, here's the result in Python with NumPy.

{noformat}
>>> import numpy as np
>>> complex0 = -2.44242319e-315
>>> complex1 = np.reciprocal(complex0)
>>> complex1
-inf
>>> np.imag(complex1)
array(0.0)
{noformat}

Here's the output with GNU Octave:

{noformat}
>> complex0 = -2.44242319E-315
complex0 =  -2.4424e-315
>> complex1 = 1./complex0
complex1 = -Inf
>> imag(complex1)
ans = 0
{noformat}

And in our case, as [~gjahanagirova] pointed, we get the following with the latest code from
git/master:

{noformat}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
System.out.println(complex1.getReal());
System.out.println(complex1.getImaginary());

# Output will be:
# -Infinity
# NaN
{noformat}

For the reciprocal value, for the three libraries the real value is -Infinity. NumPy and Octave
seem to agree that the imaginary part of the reciprocal is 0.0. But [math] says it is NaN.

>the value of complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.

Are we sure the imaginary part of the reciprocal value must be INF, instead of 0.0 as in the
other libraries?


was (Author: kinow):
Trying to make sure I understand the issue in the code.

Using -2.44242319E-315 as input, here's the result in Python with NumPy.

{noformat}
>>> import numpy as np
>>> complex0 = -2.44242319e-315
>>> complex1 = np.reciprocal(complex0)
>>> complex1
-inf
>>> np.imag(complex0)
array(0.0)
{noformat}

Here's the output with GNU Octave:

{noformat}
>> complex0 = -2.44242319E-315
complex0 =  -2.4424e-315
>> complex1 = 1./complex0
complex1 = -Inf
>> imag(complex1)
ans = 0
{noformat}

And in our case, as [~gjahanagirova] pointed, we get the following with the latest code from
git/master:

{noformat}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
System.out.println(complex1.getReal());
System.out.println(complex1.getImaginary());

# Output will be:
# -Infinity
# NaN
{noformat}

For the reciprocal value, for the three libraries the real value is -Infinity. NumPy and Octave
seem to agree that the imaginary part of the reciprocal is 0.0. But [math] says it is NaN.

>the value of complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.

Are we sure the imaginary part of the reciprocal value must be INF, instead of 0.0 as in the
other libraries?

> Method reciprocal() in Complex for complex numbers with parts very close to 0.0
> -------------------------------------------------------------------------------
>
>                 Key: MATH-1414
>                 URL: https://issues.apache.org/jira/browse/MATH-1414
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Gunel Jahangirova
>            Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and imaginary parts
are exactly equal to 0.0. In the cases when real and imaginary parts are double numbers very
close to 0.0, it does not hold. For example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of complex1.getImaginary()
will be NaN, instead of complex1 being equal to INF.
> I think the code in the method 
> {code}
> if (real == 0.0 && imaginary == 0.0) {
>       return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this case):
> {code}
> if (equals(this, ZERO, 0.01)) {
>      return INF;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message