OK,
Which branch do we want to use. As it currently is in numpy and scipy.special
arccosh(1.5) = 0.96242365011920694 arccosh(1.5+0j) = -0.96242365011920705 + 0.0j
This is consistent with gsl, but inconsistent with Mathematica, NAG, Maple, and probably all sensible implementations which use the generally accepted principal value. I've left this inconsistency raising an error in the ufunc tests until we make a decision. It might be nice to know what FORTRAN and MatLab do with this.
Chuck
Matlab is consistent, I'm afraid:
acosh(1.5)
ans = 0.9624
acosh(1.5 + 0j)
ans = 0.9624
L.
On Mon, Mar 17, 2008 at 9:40 AM, Charles R Harris charlesr.harris@gmail.com wrote:
OK,
Which branch do we want to use. As it currently is in numpy and scipy.special
arccosh(1.5) = 0.96242365011920694 arccosh(1.5+0j) = -0.96242365011920705 + 0.0j
This is consistent with gsl, but inconsistent with Mathematica, NAG, Maple, and probably all sensible implementations which use the generally accepted principal value. I've left this inconsistency raising an error in the ufunc tests until we make a decision. It might be nice to know what FORTRAN and MatLab do with this.
Chuck
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Mon, 17 Mar 2008 08:07:38 -0600, Charles R Harris wrote: [clip]
OK, that does it. I'm going to change it's behavior.
The problem with bad arccosh branch cuts is still present:
import numpy as np numpy.__version__
'1.2.0.dev5436.e45a7627a39d'
np.arccosh(-1e-9 + 0.1j)
(-0.099834078899207618-1.5707963277899337j)
np.arccosh(1e-9 + 0.1j)
(0.099834078899207576+1.5707963257998594j)
np.arccosh(-1e-9 - 0.1j)
(-0.099834078899207618+1.5707963277899337j)
np.arccosh(1e-9 - 0.1j)
(0.099834078899207576-1.5707963257998594j)
Ticket #854. http://scipy.org/scipy/numpy/ticket/854
I'll write up some tests for all the functions with branch cuts to verify that the cuts and their continuity are correct. (Where "correct" bears some resemblance to "ISO C standard", I think...)
On Thu, Jul 17, 2008 at 3:56 PM, Pauli Virtanen pav@iki.fi wrote:
Mon, 17 Mar 2008 08:07:38 -0600, Charles R Harris wrote: [clip]
OK, that does it. I'm going to change it's behavior.
The problem with bad arccosh branch cuts is still present:
import numpy as np numpy.__version__
'1.2.0.dev5436.e45a7627a39d'
np.arccosh(-1e-9 + 0.1j)
(-0.099834078899207618-1.5707963277899337j)
np.arccosh(1e-9 + 0.1j)
(0.099834078899207576+1.5707963257998594j)
np.arccosh(-1e-9 - 0.1j)
(-0.099834078899207618+1.5707963277899337j)
np.arccosh(1e-9 - 0.1j)
(0.099834078899207576-1.5707963257998594j)
Ticket #854. http://scipy.org/scipy/numpy/ticket/854
I'll write up some tests for all the functions with branch cuts to verify that the cuts and their continuity are correct. (Where "correct" bears some resemblance to "ISO C standard", I think...)
Hmm,
The problem here is arccosh = log(x + sqrt(x**2 - 1))
when the given numbers are plugged into x**2 - 1, one lies above the negative real axis, the other below and the branch cut [-inf,0] of sqrt introduces the discontinuity. Maybe sqrt(x - 1)*sqrt(x+1) will fix that. I do think the branch cut should be part of the documentation of all the complex functions. I wonder what arccos does here?
Ah, here is a reference. http://www.cs.umbc.edu/help/theory/identities.txtNote
arccosh z = ln(z + sqrt(z-1) sqrt(z+1) ) not sqrt(z**2-1)
So I guess that is the fix.
Chuck
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex arc* functions in umathmodule. It turns out that all except arccosh were OK. The formula for arcsinh was written in a non-standard form with an unnecessary nc_neg, but this didn't affect the results. I also wrote tests for checking values of the functions at infs and nans.
A patch for all of this is attached, with all currently non-passing tests marked as skipped. I'd like to commit this if there are no objections.
Another thing I noticed is that the present implementations of the complex functions are naive, so they over- and underflow earlier than necessary:
np.arcsinh(1e8)
19.113827924512311
np.arcsinh(1e8 + 0j)
(inf-0j)
np.arcsinh(-1e8 + 0j)
(-19.113827924512311-0j)
This particular thing in arcsinh occurs because of loss of precision in intermediate stages. (In the version in my patch this loss of precision is still present.)
It would be nice to polish these up. BTW, are there obstacles to using the C99 complex functions when they are available? This would avoid quite a bit of drudgework... As an alternative, we can probably steal better implementations from Python's recently polished cmathmodule.c
***
Then comes a descent into pedantry: Numpy complex functions are not C99 compliant in handling of the signed zero, inf, and nan. I don't know whether we should comply with C99, but it would be nicer to have these handled in a controlled way rather than as a byproduct of the implementation chosen.
1)
The branch cuts for sqrt and arc* don't respect the negative zero:
a = 1 + 0j np.sqrt(-a)
1j
np.sqrt(-1 + 0j)
1j
The branch cut of the logarithm however does:
np.log(-a)
-3.1415926535897931j
np.log(-1 + 0j)
3.1415926535897931j
All complex functions in the C99 standard respect the negative zero in their branch cuts. Do we want to follow?
I don't know how to check what Octave and Matlab do regarding this, since I haven't figured out how to place a negative zero in complex numbers in these languages. But at least in practice these languages appear not to respect the sign of zero.
a = 1 + 0j log(-a)
ans = 0.000000000000000 + 3.141592653589793i
log(-1)
ans = 0.000000000000000 + 3.141592653589793i
2)
The numpy functions in general don't return C99 compliant results at inf or nan. I wrote up some tests for checking these.
Do we want to fix these?
day pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.
Accidental (virus?) post. Humblest apologies for the noise. Please ignore.
Gary
On Sat, 19 Jul 2008, Gary Strangman wrote:
day pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck.Remember -- the Sunday pot-luck invite was a SHAM! The real party is on Saturday, and is not a pot-luck. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Jul 19, 2008 at 7:13 AM, Pauli Virtanen pav@iki.fi wrote:
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex arc* functions in umathmodule. It turns out that all except arccosh were OK. The formula for arcsinh was written in a non-standard form with an unnecessary nc_neg, but this didn't affect the results. I also wrote tests for checking values of the functions at infs and nans.
A patch for all of this is attached, with all currently non-passing tests marked as skipped. I'd like to commit this if there are no objections.
Another thing I noticed is that the present implementations of the complex functions are naive, so they over- and underflow earlier than necessary:
np.arcsinh(1e8)
19.113827924512311
np.arcsinh(1e8 + 0j)
(inf-0j)
np.arcsinh(-1e8 + 0j)
(-19.113827924512311-0j)
This particular thing in arcsinh occurs because of loss of precision in intermediate stages. (In the version in my patch this loss of precision is still present.)
It would be nice to polish these up. BTW, are there obstacles to using the C99 complex functions when they are available? This would avoid quite a bit of drudgework... As an alternative, we can probably steal better implementations from Python's recently polished cmathmodule.c
The main problem is determining when they are available and if they cover all the needed precisions. Since we will need standalone implementations on some platforms anyway, I am inclined towards stealing from cmathmodule.c if it offers improved code for some of the functions.
Then comes a descent into pedantry: Numpy complex functions are not C99 compliant in handling of the signed zero, inf, and nan. I don't know whether we should comply with C99, but it would be nicer to have these handled in a controlled way rather than as a byproduct of the implementation chosen.
Agreed.
The branch cuts for sqrt and arc* don't respect the negative zero:
a = 1 + 0j np.sqrt(-a)
1j
np.sqrt(-1 + 0j)
1j
The branch cut of the logarithm however does:
np.log(-a)
-3.1415926535897931j
np.log(-1 + 0j)
3.1415926535897931j
All complex functions in the C99 standard respect the negative zero in their branch cuts. Do we want to follow?
Hmm. I think so, to the extent we can. This might lead to some unexpected results, but that is what happens for arguments near the branch cuts. Do it and document it.
I don't know how to check what Octave and Matlab do regarding this, since I haven't figured out how to place a negative zero in complex numbers in these languages. But at least in practice these languages appear not to respect the sign of zero.
a = 1 + 0j log(-a)
ans = 0.000000000000000 + 3.141592653589793i
log(-1)
ans = 0.000000000000000 + 3.141592653589793i
The numpy functions in general don't return C99 compliant results at inf or nan. I wrote up some tests for checking these.
Do we want to fix these?
I'd say yes. That way we can refer to the C99 standard to document numpy behavior.
Chuck
On Sat, Jul 19, 2008 at 7:13 AM, Pauli Virtanen pav@iki.fi wrote:
Hi all,
Re: Ticket 854.
I've backported the fixes to 1.1.x, so you had better commit these ;)
Chuck
Pauli Virtanen wrote:
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex arc* functions in umathmodule. It turns out that all except arccosh were OK. The formula for arcsinh was written in a non-standard form with an unnecessary nc_neg, but this didn't affect the results. I also wrote tests for checking values of the functions at infs and nans.
Thanks for looking into these. These functions were contributed by Konrad Hinsen (IIRC) many years ago and I don't think they've really been reviewed since then.
I'm all for using C99 when it is available and improving these functions with help from cmathmodule. IIRC, the cmathmodule was contributed by Konrad originally also.
So +1 on C99 standardization.
-Travis
On Sat, 19 Jul 2008 13:29:45 -0500 "Travis E. Oliphant" oliphant@enthought.com wrote:
Pauli Virtanen wrote:
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex arc* functions in umathmodule. It turns out that all except arccosh were OK. The formula for arcsinh was written in a non-standard form with an unnecessary nc_neg, but this didn't affect the results. I also wrote tests for checking values of the functions at infs and nans.
Thanks for looking into these. These functions were contributed by Konrad Hinsen (IIRC) many years ago and I don't think they've really been reviewed since then.
I'm all for using C99 when it is available and improving these functions with help from cmathmodule. IIRC, the cmathmodule was contributed by Konrad originally also.
So +1 on C99 standardization.
-Travis
====================================================================== ERROR: test_umath.TestC99.test_catanh(<ufunc 'arctanh'>, (nan, nan), (nan, nan), '') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in arctanh
====================================================================== ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (1.0, nan), (nan, nan), '') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in log
====================================================================== ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, 0.0), (nan, nan), '') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in log
====================================================================== ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, 1.0), (nan, nan), '') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in log
====================================================================== ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, nan), (nan, nan), '') ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in log
---------------------------------------------------------------------- Ran 2070 tests in 35.424s
FAILED (SKIP=41, errors=5) <nose.result.TextTestResult run=2070 errors=5 failures=0>
Nils
On Sun, Jul 20, 2008 at 2:18 AM, Nils Wagner nwagner@iam.uni-stuttgart.de wrote:
On Sat, 19 Jul 2008 13:29:45 -0500 "Travis E. Oliphant" oliphant@enthought.com wrote:
Pauli Virtanen wrote:
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex arc* functions in umathmodule. It turns out that all except arccosh were OK. The formula for arcsinh was written in a non-standard form with an unnecessary nc_neg, but this didn't affect the results. I also wrote tests for checking values of the functions at infs and nans.
Thanks for looking into these. These functions were contributed by Konrad Hinsen (IIRC) many years ago and I don't think they've really been reviewed since then.
I'm all for using C99 when it is available and improving these functions with help from cmathmodule. IIRC, the cmathmodule was contributed by Konrad originally also.
So +1 on C99 standardization.
-Travis
====================================================================== ERROR: test_umath.TestC99.test_catanh(<ufunc 'arctanh'>, (nan, nan), (nan, nan), '')
Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in arctanh
<snip>
What architecture and OS?
Chuck
On Sun, Jul 20, 2008 at 03:34, Charles R Harris charlesr.harris@gmail.com wrote:
What architecture and OS?
I get the following on OS X 10.5.3 Intel Core 2 Duo:
====================================================================== FAIL: test_umath.TestC99.test_clog(<ufunc 'log'>, (-0.0, -0.0), (-inf, -0.0), 'divide') ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/Users/rkern/svn/numpy/numpy/core/tests/test_umath.py", line 394, in _check assert got == expected, (got, expected) AssertionError: ('(-inf, 3.1415926535897931)', '(-inf, 0.0)')
====================================================================== FAIL: test_umath.TestC99.test_csqrt(<ufunc 'sqrt'>, (-inf, 1.0), (-0.0, inf), '') ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/Users/rkern/svn/numpy/numpy/core/tests/test_umath.py", line 394, in _check assert got == expected, (got, expected) AssertionError: ('(0.0, inf)', '(-0.0, inf)')
---------------------------------------------------------------------- Ran 1887 tests in 7.716s
On Sun, 20 Jul 2008 02:34:48 -0600 "Charles R Harris" charlesr.harris@gmail.com wrote:
On Sun, Jul 20, 2008 at 2:18 AM, Nils Wagner nwagner@iam.uni-stuttgart.de wrote:
On Sat, 19 Jul 2008 13:29:45 -0500 "Travis E. Oliphant" oliphant@enthought.com wrote:
Pauli Virtanen wrote:
Hi all,
Re: Ticket 854.
I wrote tests for the branch cuts for all complex
arc*
functions in umathmodule. It turns out that all except arccosh were OK. The formula for arcsinh was written in a non-standard form with an unnecessary nc_neg, but this didn't affect the results. I also wrote tests for checking values of the
functions
at infs and nans.
Thanks for looking into these. These functions were contributed by Konrad Hinsen (IIRC) many years ago and I don't think they've really been reviewed since then.
I'm all for using C99 when it is available and
improving
these functions with help from cmathmodule. IIRC, the cmathmodule was contributed by Konrad originally also.
So +1 on C99 standardization.
-Travis
====================================================================== ERROR: test_umath.TestC99.test_catanh(<ufunc 'arctanh'>, (nan, nan), (nan, nan), '')
Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/nose-0.10.3-py2.4.egg/nose/case.py", line 182, in runTest self.test(*self.arg) File "/usr/lib/python2.4/site-packages/numpy/core/tests/test_umath.py", line 405, in _check func(point) FloatingPointError: invalid value encountered in arctanh
<snip>
What architecture and OS?
Linux linux 2.6.11.4-21.17-default #1 Fri Apr 6 08:42:34 UTC 2007 i686 athlon i386 GNU/Linux
SuSe Linux 9.3
gcc --version gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/usr/bin/python Python 2.4 (#1, Oct 13 2006, 17:13:31) [GCC 3.3.5 20050117 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Nils
Hi,
Sorry,
Sun, 20 Jul 2008 10:18:47 +0200, Nils Wagner wrote:
ERROR: test_umath.TestC99.test_catanh(<ufunc 'arctanh'>, (nan, nan), (nan, nan), '') FloatingPointError: invalid value encountered in arctanh
Skipped now.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (1.0, nan), (nan, nan), '') FloatingPointError: invalid value encountered in log
Bug in tests, fixed.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, 0.0), (nan, nan), '') FloatingPointError: invalid value encountered in log
Bug in tests, fixed.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, 1.0), (nan, nan), '') FloatingPointError: invalid value encountered in log
Bug in tests, fixed.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, nan), (nan, nan), '') FloatingPointError: invalid value encountered in log
Skipped.
Sun, 20 Jul 2008 03:42:45 -0500, Robert Kern wrote:
FAIL: test_umath.TestC99.test_clog(<ufunc 'log'>, (-0.0, -0.0), (-inf,
-0.0), 'divide')
Interesting, there's no test like this in there, only one with positive zeros. Where does this one come from?
FAIL: test_umath.TestC99.test_csqrt(<ufunc 'sqrt'>, (-inf, 1.0),
(-0.0, inf), '')
Fails on your platform, skipped.
On Sun, 20 Jul 2008 12:10:23 +0000 (UTC) Pauli Virtanen pav@iki.fi wrote:
Hi,
Sorry,
Sun, 20 Jul 2008 10:18:47 +0200, Nils Wagner wrote:
ERROR: test_umath.TestC99.test_catanh(<ufunc 'arctanh'>, (nan, nan), (nan, nan), '') FloatingPointError: invalid value encountered in arctanh
Skipped now.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (1.0, nan), (nan, nan), '') FloatingPointError: invalid value encountered in log
Bug in tests, fixed.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, 0.0), (nan, nan), '') FloatingPointError: invalid value encountered in log
Bug in tests, fixed.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, 1.0), (nan, nan), '') FloatingPointError: invalid value encountered in log
Bug in tests, fixed.
ERROR: test_umath.TestC99.test_clog(<ufunc 'log'>, (nan, nan), (nan, nan), '') FloatingPointError: invalid value encountered in log
Skipped.
Sun, 20 Jul 2008 03:42:45 -0500, Robert Kern wrote:
FAIL: test_umath.TestC99.test_clog(<ufunc 'log'>, (-0.0, -0.0), (-inf,
-0.0), 'divide')
Interesting, there's no test like this in there, only one with positive zeros. Where does this one come from?
FAIL: test_umath.TestC99.test_csqrt(<ufunc 'sqrt'>, (-inf, 1.0),
(-0.0, inf), '')
Fails on your platform, skipped.
-- Pauli Virtanen
Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Ran 2069 tests in 30.300s
OK (SKIP=44) <nose.result.TextTestResult run=2069 errors=0 failures=0>
Thank you.
Cheers, Nils