Get nth digit after decimal point

Question

What would be the most efficient way to grab the, say, 207th decimal place of a number? Would it just be x * Math.pow(10,207) % 10 ?

Answer 1

How's this for python

int((x*(10**n)))%10   

Answer 2

***Special Note: There is no: "This will handle all situations" answer here as the arbitrary value such as 207 could take the calculations way outside the bounds of possible precision of the variable types involved. My answer as such will only work within the bounds of variable type precision for which 207 is really not possible...

To get the specific digit an arbitrary number (like 207) of places after the decimal point... if you just multiply by factor of 10.. and then take mod 10, the answer (in java) is still a floating point type... not a single digit...

To get a specific digit an arbitrary number (n) of places after the decimal point, without converting to string:

Math.floor(x*Math.pow(10,n)) % 10;

to get 4th digit after 2.987654321

x*Math.pow(10, 4) = 29876.54321
Math.floor(29876.54321) = 29876
29876 % 10 = 6

Answer 3

What you want is impossible.

The only things in java that work with Math.pow and basic operators are the primitives. The only floating point primitives are float and double . These are IEEE754 floating point numbers; doubles are 64 bits and floats are 32 bits.

A simple principle applies: If you have 64 bits, then you can only represent 2^64 different numbers (it's actually a little less). So, you get about 18446744073709551616 numbers, of all numbers in existence , which actually exist as far as the computer is concerned for doubles. all other numbers do not exist .

So what happens if a mathematical operation (say, 0.1 + 0.2 ) ends up being a number that doesn't exist? Well, java (this is predicated by the IEEE754 standard; most languages and chips do it this way) will return you the nearest number amongst all the 18446744073709551616 numbers that do exist.

The problem with wanting the 207th digit is that obviously, given that only 18446744073709551616 numbers exist, none of those 18446744073709551616 numbers have that kind of precision. Asking for the 207th digit is therefore completely random. It says nothing about the input number... whatsoever.

Let me repeat that: There are no double values that have a significant 207th digit AT ALL .

If you want 'perfect' representation, with no rounding whatsoever, you want BigDecimal , but note that demanding perfection is tricky. Imagine in basic decimal math (computers are binary, but lets stick with decimal as we're all much more familiar with it, what with our 10 fingers and all), I ask you to only give me perfect answers, and then I ask you to divide 1 by 3.

BigDecimal won't let you do that either, so the ops you can run on BigDecimals without telling BigDecimal in what ways it is allowed to be inprecise leads to exceptions.

If you've set it all up exactly how you wanted it, and you really have a BigDecimal with a 207th digit after the comma, you can use the scale feature, or just the power-of-10 feature to get what you want.

Note BigDecimal is not primitive and therefore does not support the +, %, etc operators.