[issue15438] Incredible issue in math.pow

Mark Dickinson added the comment: Ah yes; a comparison like that could indeed give the impression that C/C++ was computing things exactly. :-) -- ___ Python tracker ___ ___

[issue15438] Incredible issue in math.pow

Amaury Forgeot d'Arc added the comment: C comparison rules are different from Python's. In the program below (which outputs 1), the mixed comparison will first convert the literal to a double, and lost some precision. Python does the opposite: the (imprecise) float is converted to a long, so al

[issue15438] Incredible issue in math.pow

Mark Dickinson added the comment: - I can't find any reason in using math.pow if I can get errors like the one explained. Yep---don't use math.pow if you want *exact* integer results. If you're doing numerical calculations and errors of around 1 part in 1 thousand million million are accept

[issue15438] Incredible issue in math.pow

Serhiy Storchaka added the comment: > - I can't find any reason in using math.pow if I can get errors like the one > explained. The reason is your intention to get the error. >>> pow(-1, 0.5) (6.123031769111886e-17+1j) >>> math.pow(-1, 0.5) Traceback (most recent call last): File "", line 1

[issue15438] Incredible issue in math.pow

andrea bergamini added the comment: Ok guys, ticket closed, but I'm still confused: I'm not a Python expert, I've understood that math is a sort of wrapper of C math.h or something like this, but: - I can't find any reason in using math.pow if I can get errors like the one explained. - I've u

[issue15438] Incredible issue in math.pow

Mark Dickinson added the comment: > Wouldn't that reinforce the misconception that math is for arbitrary > precision number theoretical functions? Perhaps. We already have math.factorial, though; adding math.powmod wouldn't seem so much of a stretch. Just to be clear, I'm not seriously prop

[issue15438] Incredible issue in math.pow

Stefan Krah added the comment: Ramchandra Apte wrote: > > [+1 for removing pow from the builtins and shunting three-argument pow to > > the math module in Python 500.] > Anybody who uses pow with three is doing something mathematical and has most > likely imported math already. Wouldn't

[issue15438] Incredible issue in math.pow

Ramchandra Apte added the comment: > [+1 for removing pow from the builtins and shunting three-argument pow to the > math module in Python 500.] Me too. Anybody who uses pow with to arguments can use arg1**arg2 Anybody who uses pow with three is doing something mathematical and has most li

[issue15438] Incredible issue in math.pow

Mark Dickinson added the comment: Agreed that this is at worst a doc issue. [Antoine] > and in all honesty I don't know the difference between the "**" operator > and the built-in pow() function :-) None, as far as I know, apart from the pow function's ability to take a 3rd argument. Both ul

[issue15438] Incredible issue in math.pow

Changes by Raymond Hettinger : -- components: +Documentation -Library (Lib) resolution: -> invalid ___ Python tracker ___ ___ Python-

[issue15438] Incredible issue in math.pow

Raymond Hettinger added the comment: The math module is primarily about exposing the C floating point library functions. Any integer arguments are converted to double. We could add more docs but that usually doesn't help someone who already has an expectation that math.pow does the same thin

[issue15438] Incredible issue in math.pow

R. David Murray added the comment: Your problems didn't come from the "Python" math library, it came from the C math library that Python provides a wrapper for, which the documentation does clearly state. And the result you got is accurate...for a floating point calculation. -- ___

[issue15438] Incredible issue in math.pow

andrea bergamini added the comment: Well, from a library I'm used to expect a good result or an exception. Not a value that differs from the correct of one unit! I agree with Antoine, the doc should warn about this behavior. I've lost a lot of time before discovering my application issue came

[issue15438] Incredible issue in math.pow

Antoine Pitrou added the comment: That could help, but you easily miss the title when looking up the doc for a given function. And since log2() already has a seealso for the corresponding int method, pow() could grow one as well. (and in all honesty I don't know the difference between the "**

[issue15438] Incredible issue in math.pow

Stefan Krah added the comment: How about changing the title to something like: math -- 53-bit floating point arithmetic -- ___ Python tracker ___ __

[issue15438] Incredible issue in math.pow

Stefan Krah added the comment: "Title" referring to the section header of http://docs.python.org/dev/library/math.html ... -- ___ Python tracker ___ ___

[issue15438] Incredible issue in math.pow

Antoine Pitrou added the comment: Well, the math.pow() doc could use a "seealso" pointing to the built-in pow() function perhaps. -- nosy: +pitrou ___ Python tracker ___ __

[issue15438] Incredible issue in math.pow

Stefan Krah added the comment: I think Serhiy has already explained that 43**10 is too large to be represented exactly in 53-bit floating point arithmetic. The math module wraps the floating point functions from the C standard: "It provides access to the mathematical functions defined by the C

[issue15438] Incredible issue in math.pow

R. David Murray added the comment: If I understand correctly, the math module is providing C standard (Annex F) *floating point* mathematical functions. Mark will have the definitive answer once he gets a chance to comment. Perhaps a documentation clarification is in order on this point. -

[issue15438] Incredible issue in math.pow

andrea bergamini added the comment: Ok, but math.pow IMPO has to be aligned to pow and built-in pow (**), otherwise this kind of "inaccuracies" can compromise the application behavior. I was using this funcion in a cryptographic mechanisms, and this issue resulted in a failure. Generally spe

[issue15438] Incredible issue in math.pow

Serhiy Storchaka added the comment: >>> (43**10).bit_length() 55 >>> sys.float_info.mant_dig 53 See http://docs.python.org/faq/design.html#why-are-floating-point-calculations-so-inaccurate -- nosy: +storchaka ___ Python tracker

[issue15438] Incredible issue in math.pow

Ezio Melotti added the comment: This is what I get on both 2.7 and 3.3: >>> import math >>> math.pow(43, 10) 2.161148231328425e+16 >>> pow(43, 10) 21611482313284249 >>> 43**10 21611482313284249 >>> int(math.pow(43, 10)) 21611482313284248 -- nosy: +ezio.melotti, skrah __

[issue15438] Incredible issue in math.pow

Changes by Ned Deily : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue15438] Incredible issue in math.pow

New submission from andrea bergamini : math.pow(43, 10) gives the wrong result: 21611482313284248.0 Instead, the build-in function 43**10 and pow(43, 10) give the correct result: 21611482313284249L. This bug has been seen on ActivePython 2.5.1.1. Sorry no tests on recent versions. -- c