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.

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

>>> (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

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 speaking, integer numbers should not be affected by inaccuracies. I mean, there's no floating point.

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.

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 standard."

"Except when explicitly noted otherwise, all return values are floats."


So there's no bug, and the documentation looks fine to me, too.

Well, the math.pow() doc could use a "seealso" pointing to the built-in pow() function perhaps.

How about changing the title to something like:

math -- 53-bit floating point arithmetic

"Title" referring to the section header of http://docs.python.org/dev/library/math.html ...

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 "**" operator and the built-in pow() function :-))

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 from the py math library...

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.

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 thing as int ** int.

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 ultimately call PyNumber_Power, and the various type-specific __pow__ methods take over from there.  [+1 for removing pow from the builtins and shunting three-argument pow to the math module in Python 5000000.]

> [+1 for removing pow from the builtins and shunting three-argument pow to the math module in Python 5000000.]
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 likely imported math already.

Ramchandra Apte <report@bugs.python.org> wrote:
> > [+1 for removing pow from the builtins and shunting three-argument pow to the math module in Python 5000000.]
> Anybody who uses pow with three is doing something mathematical and has most likely imported math already.

Wouldn't that reinforce the misconception that math is for arbitrary precision
number theoretical functions? The OP used it for cryptography.

> 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 proposing this for any version of Python before 4.0; apologies for derailing the issue thread.

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 used math.h in my C++ code without having experienced any problem in that pow operation.
I'm surely missing something but I'm a bit confused...

> - 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 "<stdin>", line 1, in <module>
ValueError: math domain error

> - I've used math.h in my C++ code without having experienced any problem in that pow operation.

What you get in C++ as result of pow(43, 10)?

Technically, in C++ you should use <cmath> header, not <math.h>.

- 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 acceptable to you, then math.pow works just fine.  Just like the other math functions (math.log, math.exp, math.sin, etc.), it's using floating-point arithmetic, so converts its inputs to float and gives a float result.  Unlike Python ints, which have unbounded precision, Python floats have a fixed size (64 bits), so there are only finitely many values (less than 2**64) that can be represented exactly.  The fact is that the number you were expecting, 21611482313284249, isn't one of those numbers:  it *doesn't exist* as a float, because it's not exactly representable in the usual 64-bit floating-point type that Python uses internally.

- I've used math.h in my C++ code without having experienced any problem in that pow operation.

I'd be quite surprised if this were true:  if you're using the double type with C or C++, and the pow function from math.h / cmath, you should expect to see *exactly* the same issues.  With the 'long double' type, you may get a little more precision (depending on the platform), but that just delays the point at which those issues would appear.

By the way, don't close the issue just yet!  There's still ongoing discussion here about whether
there's potential for a documentation improvement.

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 all digits are compared.


#include <math.h>
#include <stdio.h>
int main()
{
    printf("result: %d\n", (pow(43,10) == 21611482313284249));
}

Ah yes; a comparison like that could indeed give the impression that C/C++ was computing things exactly. :-)

Changing the incredible issue title :-)

> Well, the math.pow() doc could use a "seealso" pointing to the built-in
> pow() function perhaps.

Pointing to ``**`` is probably better.
I think that a simple note that mentions the ** operator and when it's better to use it (and possibly the limitations of math.pow) is enough.
Anyone wants to suggest a specific wording?

> Anyone wants to suggest a specific wording?

How about the attached patch?

I don't think it should be .. note, but otherwise it looks fine to me.

Updated patch.  Thanks Ezio and David for reviewing.

Whoops.  Removing a bonus non-grammatical 'function'.

LGTM.
(Maybe build the doc and double check that all the links are correct before committing.)

New changeset ad0712f4b3e0 by Ezio Melotti in branch '2.7':
#15438: add a note to math.pow() that suggests using **/pow() for integers.  Patch by Mark Dickinson.
http://hg.python.org/cpython/rev/ad0712f4b3e0

New changeset 7d95a0aa6b5a by Ezio Melotti in branch '3.2':
#15438: add a note to math.pow() that suggests using **/pow() for integers.  Patch by Mark Dickinson.
http://hg.python.org/cpython/rev/7d95a0aa6b5a

New changeset a305901366a6 by Ezio Melotti in branch '3.3':
#15438: merge with 3.2.
http://hg.python.org/cpython/rev/a305901366a6

New changeset e0f940829eb6 by Ezio Melotti in branch 'default':
#15438: merge with 3.3.
http://hg.python.org/cpython/rev/e0f940829eb6

Thanks, Ezio;  I didn't get around to dealing with this as quickly as I meant to.