13

If you try to run the following code

public class Main {
   public static void main(String[] args) {
       long a = (long)Math.pow(13, 15);
       System.out.println(a + " " + a%13);
   }
}

You will get "51185893014090752 8"

The correct value of 13^15 is 51185893014090757, i.e. greater than the result returned by Math.pow by 5. Any ideas of what may cause it?

Olimpiu POP
  • 5,001
  • 4
  • 34
  • 49
Maxim Mayers
  • 185
  • 2
  • 6
  • 6
    Math.pow operates and returns floating points. You can't expect perfect accuracy out of them, regardless of casting (even if the cast is "valid"). – Mat Mar 31 '12 at 13:57
  • But before you freak out about the lack of precision, there aren't many applications where one can measure to .00000000001 accuracy, therefore perfect precision wouldn't be meaningful anyway. The only common case I can think of would be when manipulating probabilities. – Tony Ennis Mar 31 '12 at 14:11
  • The cause has been named in the answers. If you need integer powers, look into `java.math.BigInteger` or commons-math `org.apache.commons.math.util.MathUtils`. – Christian Semrau Mar 31 '12 at 14:15
  • Math.pow results can be quite surprising: https://octoperf.com/blog/2018/03/16/java-math-pow/ – Jerome L Apr 23 '18 at 15:58

6 Answers6

11

You've exceeded the number of significant digits available (~15 to 16) in double-precision floating-point values. Once you do that, you can't expect the least significant digit(s) of your result to actually be meaningful/precise.

If you need arbitrarily precise arithmetic in Java, consider using BigInteger and BigDecimal.

aroth
  • 54,026
  • 20
  • 135
  • 176
6

This is not a problem of precision. The Math.pow method performs an approximation of the result. To get the correct result use the following code.

long b = 13;
for(int i = 0; i != 14; i ++) {
    b = b * 13;
}
System.out.println(b);

The output is the expected result 51185893014090757L.

More generally, the Math.pow method usage should be avoided when the exponent is an integer. First, the result is an approximation, and second it is more costly to compute.

The implementation of Math.pow (and most other methods in the Math class) is based on the network library netlib as the package "Freely Distributable Math Library" (see StrictMath javadoc). The implementation in C is available at e_pow.c.

Pierre-Nicolas Mougel
  • 2,209
  • 12
  • 18
6

The problem is that as you get to higher and higher double values, the gap between consecutive values increases - a double can't represent every integer value within its range, and that's what's going wrong here. It's returning the closest double value to the exact result.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
1

A double has finite precision, its mantissa is 52 bits, which roughly equals 15 to 16 decimals. So the number you're trying to calculate can't be represented (exactly) by a double any more.

Neet
  • 3,937
  • 15
  • 18
0

The correct answer is to provide the closest number which can be represented by a double

Have you checked whether this is the case or not?

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

it is because of the limit of holding digits in long by casting to double, float you may be able but it will have some errors, you should yourself handle the digits of the calculation by saving them in an array that's not an easy way

but in python programming language you can have the result of any length, it is so powerful!

be successful!!!

F M
  • 35
  • 4