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