10000 BUG: Increase accuracy of log1p for small inputs by mfkasim1 · Pull Request #22611 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

BUG: Increase accuracy of log1p for small inputs #22611

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.

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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
TST: Added decimal arg in testing small numbers
  • Loading branch information
mfkasim1 committed Nov 18, 2022
commit d559bcad2cc8f342d4240e6ce2f202deabb71ad4
15 changes: 10 additions & 5 deletions numpy/core/tests/test_umath.py
Original file line number Diff line number Diff line change
Expand Up @@ -1811,10 +1811,13 @@ def test_special(self):
class TestLog1pComplex:
def test_log1p_complex(self):
assert_almost_equal(ncu.log1p(0.2 + 0.3j), ncu.log(1.2 + 0.3j))
assert_almost_equal(ncu.log1p(1e-19 + 1e-18j), 1e-19 + 1e-18j)
assert_almost_equal(ncu.log1p(1e-19 + 1e-18j), 1e-19 + 1e-18j,
decimal=23)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that assert_almost_equal_nulp is the more convenient way of checking things here.

@WarrenWeckesser if you could want to dig into whether the implementation looks right, that would be great. I would still feel things would be much simpler if we can "steal" an implementation from elsewhere (that has a clearly BSD compatible license).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to centralise ideas (pytorch/pytorch#89214 (comment)), I agree. Now, it's not clear where is this function implemented for complex numbers really...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

# these numbers are obtained from wolfram alpha
assert_almost_equal(ncu.log1p(1e-18 + 0.1j), 0.00497517 + 0.0996687j)
assert_almost_equal(ncu.log1p(0.1 + 1e-18j), 0.0953102 + 9.09091e-19j)
assert_almost_equal(ncu.log1p(0.1 + 1e-18j).real, 0.0953102)
assert_almost_equal(ncu.log1p(0.1 + 1e-18j).imag, 9.0909091e-19,
decimal=23)
assert_almost_equal(ncu.log1p(0.5 + 0j), 0.40546510810816 + 0j)
assert_almost_equal(ncu.log1p(0.0 + 0.5j), 0.111571776 + 0.463647609j)

Expand All @@ -1823,14 +1826,16 @@ def test_extreme(self):
# and double checked with wolfram alpha
assert_almost_equal(ncu.log1p(-1 + 1e250j),
575.6462732485114 + 1.5707963267948966j)
assert_almost_equal(ncu.log1p(1e250 + 1j),
575.6462732485114 + 1e-250j)
assert_almost_equal(ncu.log1p(1e250 + 1j).real,
575.6462732485114)
assert_almost_equal(ncu.log1p(1e250 + 1j).imag,
1e-250, decimal=255)
assert_almost_equal(ncu.log1p(1e250 + 1e250j),
575.9928468387914 + 0.7853981633974483j)
assert_almost_equal(ncu.log1p(1e-250 + 1e250j),
575.6462732485114 + 1.5707963267948966j)
assert_almost_equal(ncu.log1p(1e-250 + 2e-250j),
1e-250 + 2e-250j)
1e-250 + 2e-250j, decimal=255)
assert_almost_equal(ncu.log1p(1e250 + 1e-250j),
575.6462732485114 + 0.0j)

Expand Down
0