Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Loss of precision in (complex) arcsinh & arctanh (Trac #1008) #1606

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
thouis opened this issue Oct 19, 2012 · 7 comments
Closed

Loss of precision in (complex) arcsinh & arctanh (Trac #1008) #1606

thouis opened this issue Oct 19, 2012 · 7 comments
Labels
00 - Bug component: numpy._core
Milestone
1.3.0

Comments

@thouis
Copy link
Contributor

thouis commented Oct 19, 2012

Original ticket http://projects.scipy.org/numpy/ticket/1008 on 2009-02-15 by @pv, assigned to unknown.

Numpy's complex arcsinh and arctanh suffer from loss of precision at small arguments:

>>> import numpy as np
>>> np.__version__
'1.3.0.dev6366'
>>> np.arcsinh(1e-50)
1e-50
>>> np.arcsinh(1e-50+0j)
0j
>>> np.arctanh(1e-50)
1e-50
>>> np.arctanh(1e-50+0j)
0j

However, complex arcsin and arctan are OK:

>>> np.arcsin(1e-50 + 0j)
(1e-50-0j)
>>> np.arctan(1e-50 + 0j)
(1e-50+0j)
@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@pv wrote on 2009-02-15

Correction: also arcsin and arctan suffer from the same loss of precision:

>>> np.arcsin(1e-50j)
-0j
>>> np.arctan(1e-50j)
0j

@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@pv wrote on 2009-02-28

Suggested fix:

@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@pv wrote on 2009-03-01

Fixed in r6520.

@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@cournape wrote on 2009-03-10

The tests fail on windows (with python 2.6 and Visual Studio 2008):

............................................................................................................................
======================================================================
FAIL: test_umath.TestComplexFunctions.test_loss_of_precision(<type 'numpy.complex128'>,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\python26\lib\site-packages\nose-0.10.4-py2.6.egg\nose\case.py", line 182, in runTest
    self.test(*self.arg)
  File "C:\Python26\Lib\site-packages\numpy\core\tests\test_umath.py", line 499, in check_loss_of_precision
    check(x_basic, 2*eps/1e-3)
  File "C:\Python26\Lib\site-packages\numpy\core\tests\test_umath.py", line 486, in check
    assert np.all(d < rtol), (np.argmax(d), x[np.argmax(d)], d.max())
AssertionError: (9, 0.99999997697414933, 1.6148915538138908e-10)

======================================================================
FAIL: test_umath.TestComplexFunctions.test_loss_of_precision(<type 'numpy.complex128'>,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\python26\lib\site-packages\nose-0.10.4-py2.6.egg\nose\case.py", line 182, in runTest
    self.test(*self.arg)
  File "C:\Python26\Lib\site-packages\numpy\core\tests\test_umath.py", line 499, in check_loss_of_precision
    check(x_basic, 2*eps/1e-3)
  File "C:\Python26\Lib\site-packages\numpy\core\tests\test_umath.py", line 486, in check
    assert np.all(d < rtol), (np.argmax(d), x[np.argmax(d)], d.max())
AssertionError: (9, 0.99999997697414933, 1.6148915538138908e-10)

----------------------------------------------------------------------

@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@pv wrote on 2009-03-10

Apparently there's loss of precision in arctanh on VS2008 not only near x=0 but also near the pole x=1.

Changed the test in r6620 so that it doesn't try to check arctanh near x=1 as fixing this is a separate issue. But to debug the issue further: what does the following print on VS2008:

>>> import numpy as np
>>> np.arctanh(0.99999997697414933)
9.1398977395072354
>>> np.arctanh(0.99999997697414933+0j)
(9.1398977395072354+0j)

ie. do the numbers match, and which one deviates?

@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@pv wrote on 2009-03-23

More fixes in r6715 - r6716: more precision for long doubles since on some platforms they are quad precision. Punched out the longdouble test if it seems that longdouble is finfo is broken on the platform.

I believe the Windows issue is also fixed; the output above looks ok.

@thouis
Copy link
Contributor Author

thouis commented Oct 19, 2012

@cournape wrote on 2009-03-12

I get this 9.13989773951 and (9.13989773951+0j) respectively.

@thouis thouis closed this as completed Oct 19, 2012
@numpy-gitbot numpy-gitbot mentioned this issue Oct 23, 2012
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy._core
Projects
None yet
Milestone
1.3.0
Development

No branches or pull requests
1 participant
@thouis