8000 BUG: npy_acosh fallback too simple. by ewmoore · Pull Request #6976 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

BUG: npy_acosh fallback too simple. #6976

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

Merged
merged 1 commit into from
Jan 8, 2016
Merged

Conversation

ewmoore
Copy link
Contributor
@ewmoore ewmoore commented Jan 8, 2016

Fixes gh-6712.

Comparing the old implementation against mpmath with 1000 digits:
figure_1
and the new implementation:
figure_2

@charris
Copy link
Member
charris commented Jan 8, 2016

LGTM. That's a pretty remarkable improvement for such a small change.

@charris
Copy link
Member
charris commented Jan 8, 2016

Apparently none of our tests uses a sufficiently old glib to test this or we would already have seen the error, so not waiting on AppVeyor here. Thanks Eric.

charris added a commit that referenced this pull request Jan 8, 2016
BUG: npy_acosh fallback too simple.
@charris charris merged commit fd1d7de into numpy:master Jan 8, 2016
@njsmith
Copy link
Member
njsmith 8000 commented Jan 8, 2016

IIUC, instead of carrying around lots of ad hoc fallbacks like this, what Julia has done is put together their own known-good portable libm, which they just use everywhere:

https://github.com/JuliaLang/openlibm

Given that it exists and is already maintained by other people, it might be worth stealing for our own use too...

@charris
Copy link
Member
charris commented Jan 8, 2016

@njsmith Several people have mentioned that. What might be interesting would be to make a separate math module with ufuncs that other projects could also use. That way scipy, for instance, could get improved math while supporting older numpy versions.

@njsmith
Copy link
Member
njsmith commented Jan 9, 2016

I guess openlibm already is "a separate math module ... that other projects could also use", and the nice thing is that someone else is worrying about maintaining it :-). I'm not sure what you mean about ufuncs, though.

@charris
Copy link
Member
charris commented Jan 9, 2016

I mean a numpy compatible Python module from which we, and others, could import ufuncs.

@njsmith
Copy link
Member
njsmith commented Jan 9, 2016

So a new package that depends on numpy? I guess this sounds like a lot more
work and like it's solving a different problem than just using openlibm in
numpy, and that I'd be tempted to tell people to upgrade numpy instead of
messing about installing a new package that would depend on numpy anyway,
but if someone wanted to do that then they certainly could.

On Fri, Jan 8, 2016 at 7:19 PM, Charles Harris notifications@github.com
wrote:

I mean a numpy compatible Python module from which we, and others, could
import ufuncs.


Reply to this email directly or view it on GitHub
#6976 (comment).

Nathaniel J. Smith -- http://vorpus.org

@argriffing argriffing mentioned this pull request Feb 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0