[issue1640] Enhancements for mathmodule

Christian Heimes <[EMAIL PROTECTED]> added the comment: The patch was part of the merge of Mark's and my trunk-math branch. It was merged into the trunk and 3.0 a while ago. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > For atanh(1): raising OverflowError is actually consistent with what > currently happens. > The only singularity that's already present in math is log(0), and it seems > that that > raises OverflowError on OS X, Linux and Windows..

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Hmmm. For atanh(1): raising OverflowError is actually consistent with what currently happens. The only singularity that's already present in math is log(0), and it seems that that raises OverflowError on OS X, Linux and Windows... I wonder whether this is

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > - it doesn't touch errno, but lets the platform decide how to handle errors > (i.e. produce a > special value/set errno/signal a floating-point exception/some combination of > these). This will > make the asinh, acosh, atanh functio

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Also: -1.0 shouldn't be returned at this level to indicate an error; these are pure C functions we're writing---the Python wrappers, and Python error conventions, apply further up the chain somewhere. Just so I'm doing something a little more constructive

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: One more comment: the Py_IS_NAN test in acosh is likely never reached, since the comparison x >= two_pow_p28 will probably evaluate to 0 when x is a NaN. __ Tracker <[EMAIL PROTECTED]> ___

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Also, for the C-level routines, atanh(1.0) and atanh(-1.0) should definitely return infinity and -infinity (and probably set errno as well.) Note that this is not an argument about what Python should do: Python will still raise a ValueError for atanh(1.0) a

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: The problem with atanh is that it should be using absx throughout, rather than x. So in "if (absx < 0.5)" branch and the following branch, replace all occurrences of x with absx, and it should work. One other comment: asinh shouldn't directly set errno for

[issue1640] Enhancements for mathmodule

Changes by Guido van Rossum: -- nosy: -gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue1640] Enhancements for mathmodule

Changes by Christian Heimes: Removed file: http://bugs.python.org/file9243/trunk_pymath_hyberbolic.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu

[issue1640] Enhancements for mathmodule

Changes by Christian Heimes: Removed file: http://bugs.python.org/file9250/trunk_pymath_hyberbolic_complex.patch __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1640] Enhancements for mathmodule

Changes by Christian Heimes: Removed file: http://bugs.python.org/file8975/trunk_mathmodule.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue1640] Enhancements for mathmodule

Changes by Christian Heimes: Removed file: http://bugs.python.org/file8989/trunk_math_sign_inf_nan.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: I disabled the tests for atanh0022 and atanh0023. Other changes: Added math.log1p + tests Added SUN license to Doc/licenses.rst Added docs to Doc/library/math.rst Added file: http://bugs.python.org/file9251/trunk_pymath_hyberbolic_complex2.patch ___

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > Sorry: I should have read more carefully. So math.atanh works on Linux > but is producing some strange results on Windows. > > It's still rather puzzling though. I still suspect that it's the > argument to log1p that's coming out w

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Sorry: I should have read more carefully. So math.atanh works on Linux but is producing some strange results on Windows. It's still rather puzzling though. I still suspect that it's the argument to log1p that's coming out wrong rather than the result.

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > Mark Dickinson added the comment: > > Christian: would it be possible for you to tell me what the argument of the > log1p call is on Windows in that last branch of c_atanh, for the testcase > atanh0022. > > On OS X I get: > > Input

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Sorry: those lines should have been: double temp = 1-z.real; printf("temp is %.19e\n", temp); r.real = log1p(4.*z.real/(temp*temp + ay*ay))/4.; __ Tracker <[EMAIL PROTECTED]> __

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Okay: here's an attempted guess at what's happening on Windows: Near the end of c_atanh, there's a line that reads: r.real = log1p(4.*z.real/((1-z.real)*(1-z.real) + ay*ay))/4.; Somehow, when z.real is 0.99989 and ay is 0, the argument to log1p i

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Christian: would it be possible for you to tell me what the argument of the log1p call is on Windows in that last branch of c_atanh, for the testcase atanh0022. On OS X I get: Input to log1p is 3.2451855365842669075e+32 It's hard to imagine that there's anyt

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Christian: I'm definitely not proposing atanh(1) = inf: it should raise ValueError. I'm proposing that we follow Tim's rules for now; this means no change for finite inputs. The new thing here is that since you've made inf and nan more accessible and cons

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: It's most probably the fault of log1p(): AssertionError: atanh0022:atanh(-0.99989) returned -18.36840028483855, expected -18.714973875118524 __ Tracker <[EMAIL PROTECTED]>

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: I've added your complex patch and its tests to my patch. The tests are showing some flaws in the atanh (or log1p) function on Windows: AssertionError: atanh0022:atanh(-1.00) returned -18.36840028483855, expected -18.714973875118524 On Linux the tests are

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: The mail interface screwed up the message: >>> math.atanh(.) 18.714973875118524 >>> math.atanh(.9) Traceback (most recent call last): File "", line 1, in ValueError: math domain error __ Track

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > So e.g. cos(infinity) should give a ValueError, while log(infinity) and > exp(infinity) > should not raise any Python exception, but should return an infinity instead. > And most > single variable operations should return an input N

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Thanks, Tim! Dare I suggest extending these rules to encompass things like sqrt(NaN), log(inf), etc., as follows: - return a special value in Python where IEEE-754r/C99 specifies a special value, but doesn't raise any of the three divide-by-zero, invalid,

[issue1640] Enhancements for mathmodule

Tim Peters added the comment: Mark, these are the "spirit of 754" rules: 1. If the mathematical result is a real number, but of magnitude too large to approximate by a machine float, overflow is signaled and the result is an infinity (with the appropriate sign). 2. If the mathematical result is

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: George: I think my last post was a bit rude. I apologize if it came across that way. Mathematical rigor and IEEE-754 recommendations aren't necessarily in conflict here, though. For example, the natural log function from (0, infinity) to (-infinity, infi

[issue1640] Enhancements for mathmodule

George Castillo added the comment: I misunderstood the rationale for the function returning infinite at those points - I didn't realize that C99 was the governing force behind the implementation of these functions, rather than mathematical rigor. Thanks for pointing it out. In that case, I agre

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: No: IEEE-754r and the C99 standard both say clearly that atanh(1) should be infinity and atanh(-1) should be -infinity, and furthermore that the 'divide-by-zero' exception should be raised rather than the 'invalid' exception. It's a singularity, just like

[issue1640] Enhancements for mathmodule

George Castillo added the comment: Just a quick addition here regarding the singularities to these functions. The atanh(x) is only defined for |x| < 1, so atanh(1) or atanh(-1) isn't singular there so much as simply isn't defined. So, even though the function approaches infinite as x -> 1, it w

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Okay: for now, I guess we just follow the pattern that already exists on Linux and Windows. I think the OS X sqrt(-1) behaviour is a bug. __ Tracker <[EMAIL PROTECTED]> ___

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > Currently, on Linux I get: > - overflow (exp(1000))-> OverflowError > - domain error (sqrt(-1)) -> ValueError > - singularity (log(0))-> OverflowError Windows raises the same exceptions as Linux. _

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: whoops. OverflowError should be something else in the previous post; of course, OverflowError is inappropriate for domain errors (but entirely appropriate for something like exp(1000)). Currently, on Linux I get: - overflow (exp(1000))-> OverflowError

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: One question: is there a policy on what should happen for singularities and domain errors? If not, I think it would be useful to have one. Following the policy may not be achievable on all platforms, but it should be easy to do on major platforms, and at l

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Excellent! I'll take a look. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: I'm +1 in adding fallbacks for important functions like copysign, asinh, acosh and atanh. expm1 and log1p may be worth adding, too. Windows doesn't have any of the functions except of _copysign(). But why write our own version if we can reuse existing implemen

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: George: I'm certainly still interested in having asinh, acosh and atanh in math---I'm not sure about anyone else, but I consider these three functions to be basic ingredients in any math library. They even appear in most calculus texts. And the complex ver

[issue1640] Enhancements for mathmodule

George Castillo added the comment: Is there still interest in implementing the inverse hyperbolic trig functions for real numbers? I would be willing to explore this if there is. -- nosy: +gmcastil __ Tracker <[EMAIL PROTECTED]>

[issue1640] Enhancements for mathmodule

Tim Peters added the comment: The functionality of what was called (and I agree confusingly so) "sign()" here is supplied by "signbit()" in C99. That standard isn't free, but the relevant part is incorporated in the free Open Group standards: http://www.opengroup.org/onlinepubs/95399/functi

[issue1640] Enhancements for mathmodule

Guido van Rossum added the comment: OK, just check it in then, but do add docs! On Jan 3, 2008 2:03 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > Well, the Python API in the math module should always be called copysign().

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Guido van Rossum wrote: > Well, the Python API in the math module should always be called copysign(). > :-) > > And what to do if neither is present? Are there any systems without it? takes care of it. It's a macro to define a function which accepts two floa

[issue1640] Enhancements for mathmodule

Guido van Rossum added the comment: > Guido van Rossum wrote: > > Good idea. Since you seem to like providing patches, can you create > > one for math.copysign()? > > Don't forget it's copysign() on Unix but _copysign() on Windows. > > #if defined(MS_WINDOWS) || defined(HAVE_COPYSIGN) > #ifdef MS

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Guido van Rossum wrote: > Good idea. Since you seem to like providing patches, can you create > one for math.copysign()? Don't forget it's copysign() on Unix but _copysign() on Windows. #if defined(MS_WINDOWS) || defined(HAVE_COPYSIGN) #ifdef MS_WINDOWS FUNC2

[issue1640] Enhancements for mathmodule

Guido van Rossum added the comment: > Why not implement copysign? It's a standard, familiar function with well- > documented meaning all over the web, and it can easily be used to create > whatever sign test is necessary, letting the user decide what results > (s)he wants for +/-0, +/-nan, etc.

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Why not implement copysign? It's a standard, familiar function with well- documented meaning all over the web, and it can easily be used to create whatever sign test is necessary, letting the user decide what results (s)he wants for +/-0, +/-nan, etc. ___

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Guido van Rossum wrote: > Hm, OK, but then passing a zero of some other type (e.g. int) should > also return +1 as the sign. I also think the function's name should be > changed, because I (and I assume many others) have grown up with a > sign() function that

[issue1640] Enhancements for mathmodule

Guido van Rossum added the comment: > > One nit: you added a blank line to the end of test_math.py. > > This will cause the checkin to fail. :-) > > *grr* stupid white space check hook No, you edited a line that didn't need editing. :-) > > One bigger issue: the sign() function doesn't seem to

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > One nit: you added a blank line to the end of test_math.py. > This will cause the checkin to fail. :-) *grr* stupid white space check hook > One bigger issue: the sign() function doesn't seem

[issue1640] Enhancements for mathmodule

Guido van Rossum added the comment: One nit: you added a blank line to the end of test_math.py. This will cause the checkin to fail. :-) One bigger issue: the sign() function doesn't seem to work properly for nans. E.g. on Linux I get: >>> inf = 1e1000 >>> nan = inf/inf >>> mnan = -nan >>> mat

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: The trunk_math_sign_inf_nan patch contains just three new method isnan(), isinf() and sign(). It also fixes a minor numerical issue with one function that did small / (small / large) instead of small * (large / small). Added file: http://bugs.python.org/file89

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > i suggest abandoning any attempts at implementing math ourselves. I > also suggest not combining this with #1635 but reviewing and > (eventually) applying the latter first. How do you like a c

[issue1640] Enhancements for mathmodule

Guido van Rossum added the comment: i suggest abandoning any attempts at implementing math ourselves. I also suggest not combining this with #1635 but reviewing and (eventually) applying the latter first. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Unfortunately, implementing asinh, acosh, atanh correctly is not as simple as just using the formulas (this is one of the reasons that it's useful to be able to get at the library definitions). For example, the formula asinh(x) = log(x + sqrt(1.+(x*x))) ha

[issue1640] Enhancements for mathmodule

Christian Heimes added the comment: Mark Dickinson wrote: > Mark Dickinson added the comment: > > Cool! If there's a move to add functions to the math module, there are > some others that are part of C99 (but not C89), would be good to have, and > that I'd consider more fundamental than the Be

[issue1640] Enhancements for mathmodule

Adam Olsen added the comment: Minor typo. Should be IEEE: "Return the sign of an int, long or float. On platforms with full IEE 754\n\" -- nosy: +rhamphoryncus __ Tracker <[EMAIL PROTECTED]>

[issue1640] Enhancements for mathmodule

Mark Dickinson added the comment: Cool! If there's a move to add functions to the math module, there are some others that are part of C99 (but not C89), would be good to have, and that I'd consider more fundamental than the Bessel, error, gamma functions; for example, the inverse hyperbolic t

[issue1640] Enhancements for mathmodule

Changes by Christian Heimes: -- dependencies: +Float patch for inf and nan on Windows (and other platforms) __ Tracker <[EMAIL PROTECTED]> __ __

[issue1640] Enhancements for mathmodule

New submission from Christian Heimes: The patch adds several small enhancements to the math module and pyport.h. * Py_MATH_PI and Py_MATH_E in long double precision * Py_IS_NAN and Py_IS_INFINITY use isnan() and isinf() functions were available (checked by configure) * isnan and isinf for the ma