8000 arccosh is inaccurate when numpy is built with old glibc? · Issue #6712 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

arccosh is inaccurate when numpy is built with old glibc? #6712

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
argriffing opened this issue Nov 23, 2015 · 5 comments
Closed

arccosh is inaccurate when numpy is built with old glibc? #6712

argriffing opened this issue Nov 23, 2015 · 5 comments
Labels
00 - Bug component: npy_math

Comments

@argriffing
Copy link
Contributor

An arccosh test is failing in one of the TravisCI scipy configurations that builds numpy. I'm speculating that this is because TravisCI runs a somewhat old Ubuntu with a glibc that has some trig function implementations that numpy has blacklisted. If that is true, could this be fixed in a way that is better than bumping the scipy test tolerances or upgrading the TravisCI platform?
scipy/scipy#4729
@charris
Copy link
Member
charris commented Nov 23, 2015

Note that cacosh is not blacklisted for glibc earlier than 2.16 . Maybe is should be?

@argriffing
Copy link
Contributor Author

Note that cacosh is not blacklisted for glibc earlier than 2.16 . Maybe it should be?

You are right, I just checked it with a small C program on a Ubuntu 12.04 VM and cacosh is inaccurate. The same C program built on newer Ubuntu is accurate. But I'm not sure if the numpy fallbacks for arccosh are better; at least one of them is not:

#ifndef HAVE_ACOSH
double npy_acosh(double x)
{
    return 2*npy_log(npy_sqrt((x + 1.0)/2) + npy_sqrt((x - 1.0)/2));
}
#endif

@charris
Copy link
Member
charris commented Nov 23, 2015

@ewmoore Provided the code for the blacklisted functions, so maybe he would be interested in doing more fixups.

@argriffing
Copy link
Contributor Author

Here's the C code I was using. It prints 0 with the good C library and something like 1e-13 with the bad C library.

#include <math.h>
#include <complex.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
  const double x = 1.000001430511474609375;
  const double y = 0.001691455665129294448190238354291760044433;
  const double z = creal(cacosh(x));
  printf("%g\n", (z - y) / y);
  return 0;
}

@argriffing argriffing mentioned this issue Dec 11, 2015
Open
@argriffing
Copy link
Contributor Author

apparently Julia has a bsd(?) libm to solve problems like this, see https://github.com/JuliaLang/openlibm/blob/master/src/e_acosh.c

Edit I see this has already been mentioned #6081 (comment)

@argriffing argriffing mentioned this issue Jan 8, 2016
Closed
@charris charris added this to the 1.11.0 release milestone Jan 8, 2016
ewmoore added a commit to ewmoore/numpy that referenced this issue Jan 8, 2016
@ewmoore
BUG: npy_acosh fallback too simple.
3af3753 
Fixes numpygh-6712.
@ewmoore ewmoore mentioned this issue Jan 8, 2016
Merged
@argriffing argriffing mentioned this issue Feb 2, 2016
Closed
jaimefrio pushed a commit to jaimefrio/numpy that referenced this issue Mar 22, 2016
@ewmoore @jaimefrio
BUG: npy_acosh fallback too simple.
4b29663 
Fixes numpygh-6712.
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: npy_math
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@charris @argriffing
0