Mathematics Stack Exchange is a question and answer site for people studying math at any level and professionals in related fields. It only takes a minute to sign up.
Sign up to join this community
Is there a general method for testing numbers to see if they are perfect $n$th powers?
For example, suppose that I did not know that $121$ was a perfect square. A naive test in a code might be to see if $$\lfloor\sqrt{121}\rfloor=\sqrt{121}$$
But I imagine there are much more efficient ways of doing this (if I'm working with numbers with many digits).
See Detecting perfect powers in essentially linear time - Daniel J. Bernstein:
https://cr.yp.to/papers/powers-ams.pdf
Bernstein also has an updated algorithm which can be found here: https://cr.yp.to/papers.html#powers2
In the specific case where you already know not only the number being checked but also the power, as the question's comment by the OP to Servaes states, then you have something like
$$k = a^n \tag{1}\label{eq1}$$
where $k$ and $n$ are known integers, but with $a$ being an unknown value to check whether or not it's an integer. For $n$ not being too large, one relatively fast & easy way to show that $a$ is not an integer is get all factors of $n$ and check those which are $1$ less than a prime. In those cases, Fermat's little theorem shows that $k$ must be congruent to $0$ or $1$ modulo this prime. If it's not, then $a$ can't be an integer. Doing this test is especially useful if you are using a fixed value of $n$ and checking many values of $k$.
If you don't do the initial check above or it passes, you can next perhaps use a function to get the $n$'th root, such as using the "pow" function in C/C++ with a second argument of $\frac{1.0}{n}$, to get something like
$$a = \sqrt[n]{k} \tag{2}\label{eq2}$$
As for speed & accuracy issues, I once did a test on all integers from $1$ to $5 \times 10^{11}$ to get their sixth roots (using pow), then cubing them by multiplying together $3$ times, plus another test getting all square roots directly (using sqrt), and then finding the maximum of the absolute & relative differences. Note I used VS 2008 on an AMD FX(tm)-8320 Eight-Core Processor, 3.5 GZ, 8 GB RAM, 8 MB L2 & L3 cache, and 64-bit Windows 7 computer. Square roots took 16403 seconds, while sixth roots then cubing took 37915 seconds. Max. actual difference was $8.149\ldots \times 10^{-10}$ and relative difference was $1.332\ldots \times 10^{-15}$. This gives an indication of how relatively fast & accurate the library routines are, although results will obviously vary depending on the compiler & machine involved.
Alternatively, taking natural logarithms of both sides (you could use any base, but I suspect that implementation wise $e$ will likely at least be the fastest one, if not also the most accurate) gives
$$\ln(k) = n\ln(a) \; \Rightarrow \; \ln(a) = \frac{\ln(k)}{n} \; \Rightarrow \; a = e^{\frac{\ln(k)}{n}} \tag{3}\label{eq3}$$
As this involves $2$ basic steps of taking a logarithm and then exponentiating, this may take longer & involve a larger cumulative error than using \eqref{eq2} instead.
Using either method, on a computer, will give a floating point value that would be, even for large values of $k$, relatively close to the correct value of $a$.
You can now use any number of algorithms to relatively quickly & easily determine $a$ if it's an integer, or show it's not an integer. For example, you can start with the integer part obtained in \eqref{eq2}, call it $a_1$, to determine $k_1$. If $k_1$ is not correct, then if it's less than $k$, check $a_2 = a_1 + 1$, else check $a_2 = a_1 - 1$, and call the new result $k_2$. If $k_2$ is still not correct, add or subtract the integer amount (making sure it's at least 1) of $\left|\frac{k -k_2}{k_1 - k_2}\right|$ to $a_2$ to get a new $a_1$ value to check. Then repeat these steps as many times as needed. In almost all cases, I believe it should take few loops to find the correct value. However, note you should also include checks in case there is no such integer $a$, with this usually being determined when one integer value gives a lower result & the next higher gives a higher result (or higher result & next lower integer gives a lower result).
As for overall speed & accuracy type issues, this depends a lot on aspects like the machine, compiler, number types & final algorithm used. I assume the values fit within 64-bit unsigned integers since most machines don't have native integer types larger than this, larger floating-point values have difficulties with representing all integers (e.g., you get situations where $f + 1.0$ is stored as $f$) & packages providing a larger # of integer bits can be fairly slow. As my earlier test results show, the root calculations took an average of less than $10^{-7}$ seconds each, i.e., a few hundred machine instructions at the most. The accuracy for a single calculation would be better than the $10^{-10}$ for multiple ones, with it likely being at least around $10^{-12}$. Assuming the value of $a$ only goes up to about $10^{17}$ (as the max. value for an unsigned integer is about $1.85 \times 10^{19}$), this would give a maximum initial error of $a$ being at the most in the thousands. The algorithm I propose to determine the final value should usually reduce the error by at least a factor of $2$ each time, so it shouldn't take more than about $10$ or $20$ iterations. Getting the value of $a^n$ to check can be done relatively quickly by starting with $a$, repeatedly squaring the result & then multiplying together the ones needed based on the base $2$ representation of $n$, so it will take on the order of $\log_2 n$ operations. Overall, it should usually take at most a few thousand machine instructions, for a time of around a micro-second (i.e., $10^{-6}$ seconds) on most computers.
My suggestion on a computer is to run a root finder.
Given a value $y$, one way is to hard-code the first couple and then use an integer-valued binary search starting with $y/2$, which is logarithmic in $y$ and thus linear (since input takes $\ln y$.
You can also write down the Newton's method recurrence and see if it converges to an integer or not, should become clear after the first couple of steps, once the error becomes small enough.
It is at least possible to do this in polynomial time. Assume $n$ is a $k$-bit number and you want to find positive integers $a$ and $b$ such that $$a^b=n\tag{1}$$ or prove that such numbers don't exists.
We have $$n<2^k$$ because $n$ is a $k$-bit number and so $$b\lt k$$
We can simply check for all possible $b$ if there is an $a$ such that $(1)$ holds. For given $b$ we can try to find $a$ by bisection. This bisection checks $O(\log n)=O(k)$ different $a$. A check is the calculation of $a^b$. This can be achieved by multiplying powers of $a$ by $a$. These powers of $a$ are smaller than $n$. So we multiply $k$-bit numbers at most $b(\lt k)$ times. A multiplication of two $k$-bit numbers needs $O(k^2)$ time. So all in all the algorithm needs $O(k^2)$ multiplications o $k$-bit numbers, which means $O(k^4)$ time.
