Sebastien Binet bi...@cern.ch added the comment:
hi there,
it seems there is still a problem, at least with asinh(-2j)
see:
$ python
Python 2.6.5 (r265:79063, Apr 1 2010, 05:28:39)
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
Mark Dickinson dicki...@gmail.com added the comment:
Python's result looks fine to me, as does numpy's: they're both giving a valid
inverse hyperbolic sine:
from cmath import sinh
sinh(1.3169578969248166-1.5707963267948966j)
(1.0605752387249067e-16-1.9998j)
Mark Dickinson dicki...@gmail.com added the comment:
A bit more explanation: Python takes account of the sign of zero when deciding
which side of the branch cut a value lies, which is the proper thing to do when
you have signed zeros available (according to the likes of Kahan, anyway); I
Sebastien Binet bi...@cern.ch added the comment:
hi Mark,
that may very well be so, but I'd naively standardize on C/Fortran behaviour
(but that's probably my physicist bias)
on my platform, the following piece of C-code:
$ cat test_cmath.c
#include complex.h
#include stdio.h
int main(int
Mark Dickinson dicki...@gmail.com added the comment:
that may very well be so, but I'd naively standardize on C/Fortran
behaviour (but that's probably my physicist bias)
Yep, that's exactly what Python does. :) (Also follows the LISP standard).
Note that in your program, you're feeding
Mark Dickinson dicki...@gmail.com added the comment:
Note that in your program, you're feeding complex(-0.0, -2.0) to asinh,
not complex(0.0, 2.0).
Bah; that should be complex(0.0, -2.0) in the second line, of course.
Anyway, try passing conj(2*I) to asinh in your C program and see what
Sebastien Binet bi...@cern.ch added the comment:
Note that in your program, you're feeding complex(-0.0, -2.0) to asinh,
not complex(0.0, -2.0).
ah!
(ducking)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1381
Changes by Jesús Cea Avión [EMAIL PROTECTED]:
--
nosy: +jcea
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1381
___
___
Python-bugs-list mailing list
Mark Dickinson [EMAIL PROTECTED] added the comment:
Substantial fixes for the cmath module went into the trunk and the py3k
branches as part of the merge of the trunk-math branch. These fixes
address the asinh problems in this issue, amongst other things. See
r62380 (trunk) and r62384
Christian Heimes added the comment:
See #1640 and svn+ssh://[EMAIL PROTECTED]/python/branches/trunk-math
--
components: +Extension Modules -Library (Lib)
keywords: +patch
priority: - normal
versions: +Python 3.0 -Python 2.5
__
Tracker [EMAIL PROTECTED]
Christian Heimes added the comment:
Guido, how do you like the idea of Include/pymath.h and Python/pymath.c
containing supplementary mathematical functions and mathematical
constants? Mark's patch for cmath is rather large, can it still be
applied to 2.5?
--
nosy: +gvanrossum
versions:
Guido van Rossum added the comment:
Are you crazy? Adding new features to 2.5? No way!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1381
__
___
Python-bugs-list mailing list
Mark Dickinson added the comment:
A note to any potential reviewers for this patch (cmath3.patch): I'm
especially
looking for non-mathematical feedback here, so please don't be put off by the
mathematics. Some questions:
- there's a new file cmath.ctest containing testcases; should this
Mark Dickinson added the comment:
Okay: would it be okay for me to move the #ifdef MS_WINDOWS sequence
somewhere where it can be used by both mathmodule.c and cmathmodule.c,
then?
There are replacements for log1p and asinh in the patch, so it shouldn't
matter than they're missing on
Christian Heimes added the comment:
* I've added a configure test for copysign a while ago. I'm using this
constructor for Windows compatibility in mathmodule.c:
#ifdef MS_WINDOWS
# define copysign _copysign
# define HAVE_COPYSIGN 1
#endif
#ifdef HAVE_COPYSIGN
#endif
I know no platform
Mark Dickinson added the comment:
Here's an updated patch for cmath, complete with tests and documentation
changes.
There's an extra file, Lib/test/cmath.ctest, containing test values for the
various functions;
these test values were obtained using MPFR and interval arithmetic, and (modulo
Mark Dickinson added the comment:
Here is (quite a large) patch, cmath.patch, that fixes a variety of
problems in the current cmath module. A summary of the changes:
* sqrt, log, acos, acosh, asin, asinh, atan, atanh no longer produce
overflow errors for very large inputs
* exp, cos, sin,
Mark Dickinson added the comment:
I took a look at this a while back, and got as far as writing a pure
Python drop-in replacement for cmath, based on Kahan's branch cuts for
elementary functions paper. This fixes a variety of problems in cmath,
including the buggy branch cuts for asinh.
Martin v. Löwis added the comment:
It would be ok if a test is only run on a system with IEEE floats, and
skipped elsewhere. For all practical purposes, Python assumes that all
systems have IEEE float.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1381
New submission from Andreas Kloeckner:
This here basically says it all:
import cmath;[cmath.asinh(i*1e-17).real for i in range(0,20)]
[4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
Martin v. Löwis added the comment:
Can you propose a patch?
--
nosy: +loewis
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1381
__
___
Python-bugs-list mailing list
Andreas Kloeckner added the comment:
On Samstag 03 November 2007, Martin v. Löwis wrote:
Martin v. Löwis added the comment:
Can you propose a patch?
Other than point at how boost.math does things, I don't have the time to work
on this right now, sorry.
Andreas
Alan McIntyre added the comment:
I have to review a few complex math topics for some of my current course
work, so I wouldn't mind taking a look into this. I can't promise I'll
have the time required to make all of cmath correct (assuming it's as
unsound as claimed), but I'll do what I can.
23 matches
Mail list logo
