Reversing Digits
September 4, 2015
After Tuesday’s exercise on Lychrel numbers, I answered a question about Lychrel numbers over at Stack Overflow, using a recursive function to extract and reverse the digits one-by-one. I was challenged by a reader who claimed “using int("".join(reversed(str(n))))
has got to be far more efficient than using your recursive function. Your function is clever, but clever isn’t always best.” He was wrong, of course: arithmetic on numbers is better than converting a number to a string, creating a generator to reverse the individual characters of the string, appending them one-by-one to a new string, and converting the new string back to a number, which I demonstrated to him in a timing experiment.
Your task is to find the best way to reverse the digits of a positive integer, in the language of your choice. When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.
In Python. On my machine, the clear winner is “reverse”. The “arithmetic” version is the slowest.
Oeps. In my last post the number was hardcoded. Anyway, thease timings are OK:
number: 12345123451234512345123451234512345
reverse 0.17244116711310897
reverse2 0.32812997116085263
reverse3 2.555884828145366
The function below is some 7% faster with repeated use than “reverse”.
Reader is right for large numbers.
E.g. n = 2 ** 2048 is a number with 616 digits. Using Paul’s reverse algorithms, we see that the mathematical version is ~40 times slower than the string reverse int cast version.
On the other hand, for example for n = 32 the math version is ~2 times faster.
The answer to this question is therefor:
if n < threshold:
return reverse3(n)
else:
return reverse0(n)
with an environment dependent threshold value (threshold = 1000 here).
Here a few more timings.
Presumably the string reverse function in Python mainly involves a couple of calls to no doubt highly optimized library functions for reading and writing bignums, rather than rattling around the byte code interpreter loop a bazillion times for the arithmetic solution. In a properly compiled language like Haskell though, the string solution will still win out, but only for much larger inputs, we need 1000 digits or so before rev2 beats rev1:
On the other hand, the string implementation only wins because the library has better algorithms for radix conversion, various divide and conquer strategies are possible, for example, but we can do the same thing arithmetically.
Here, we determine how many digits are needed with integer log 10, split the number in half, recurse and then rejoin the reversed halves. For the base case we just use the iterative solution, taking care to produce a reverse of the right width (and we can do this with efficient fixed width Ints rather than variable width Integers). With a nice integer log implementation by Remco Niemeijer taken from an earlier Programming Praxis problem, it takes about 3 seconds to reverse a million digit number, versus a minute for the string solution:
Reblogged this on A Modern Prometheus and commented:
The following is the METAL BASIC 1.0ß source code output by a pre-compiler I wrote as a potential A level Computing project.
#include
int main()
{
int num=12345,l=0,val=0;
for(;num;val=val*10+(num%10),num/=10);
printf(“number = %d\n”,val);
}