Comments on: Palindrome Numbers

By: Dave S

Dave S — Wed, 17 Jun 2009 05:44:11 +0000

Hi! I know this is for MATLAB but I was very interested in doing this a different way. I’m using PHP to do the same thing. I have a web page up to play with. I used bcadd() and strrev() to find the palindrome and do the sums with infinite precision.

http://www.mrsankey.com/pal.php

I don’t feel like escaping the code right now. I’m tired. It wasn’t that tricky. Add and check, add and check, blah, blah…

We cannot assume that any of these numbers will not converge eventually, no matter how improbable. The number 10715 converges after 547 iterations. I haven’t found a number that doesn’t converge until you get above 1000 iterations. There seemed to be a ceiling around 760. Maybe we should offer a prize?

By: Mike Garrity

Mike Garrity — Wed, 08 Apr 2009 19:53:15 +0000

Yes, 196, 295, 394, et al are called “kin numbers” and they converge on the same “thread”. The lowest number that leads to a thread is called the “seed”, so that would be 196 in this case. I think that the next seed after 879 is 1997.

I’ve been trying to come up with a good visual representation of the threads. It’s tough because they’re a very sparse set in a very big, linear space, but there are clearly some interesting patterns in how the threads are interwoven.

By: Yi Cao

Yi Cao — Wed, 08 Apr 2009 16:18:29 +0000

Some numbers are clearly of this class. From 196, then 691, and 196+691=887. Then numbers, which can reach 887 are of this class, i.e. 196, 295, 394, 493, 592, 691, 788, 790 and 887. Further more, 689 and 986 this is because 689 + 986 = 1675 = 887 + 788. However, I do find another pair numerically, 879 and 978, which does not converge to (887, 788) pairs quickly.

By: Loren

Loren — Wed, 08 Apr 2009 15:07:39 +0000

Another way to work with these numbers is via the Symbolic Math Toolbox.

reversechars = @(x) sym(fliplr(char(x)))
x = sym(124)
x = x+reversechars(x)
...

--Loren

By: Daniel

Daniel — Wed, 08 Apr 2009 14:48:38 +0000

@Mike
Yeah, my actual code has a test in it to detect precision problems. For starting numbers less than 10000, precision was not a problem.

BTW, shouldn’t one be able to speed things up by alot if one used not one digit per piece but as many as can be fit in a 32-bit number. Then you just check if you have a carry on the most significant digit… just a thought.

By: matt fig

matt fig — Tue, 07 Apr 2009 16:30:01 +0000

I think John D’Errico’s variable precision integer toolbox could come in handy for large numbers!

By: Mike Garrity

Mike Garrity — Tue, 07 Apr 2009 12:32:24 +0000

Yes, your version is faster, but you need to worry about the fact that the numbers can get very large when you’re doing this. For example, try this starting value: 1000689. It should take 78 turns to converge on 796,589,884,324,966,945,646,549,669,423,488,985,697. If you store that in a double precision number, you’ll only get the first 16 digits. You can’t check whether it’s a palindrome without having all 39 digits.

It is possible to get your approach to work, but you’ll need to detect when you’re about to start losing precision and break your number into pieces. I found it easier to just start out with the number in pieces. Of course my version is using a double precision value to represent each digit. That’s obviously overkill. You really only need ~3.3 bits per digit rather than 64.

By: Daniel

Daniel — Tue, 07 Apr 2009 06:58:53 +0000

It seems that just below every multiple of 100 there is at least one non-converging. Numbers just above an even multiple of 100 are either palindrome themselves or become so fast.

By: Daniel

Daniel — Tue, 07 Apr 2009 06:28:43 +0000

Well, with all due respectr, improving on that code wasn't too difficult. The way you convert numbers to arrays and then implement your own addition isn't very efficient. I used a trick Loren mentioned a while back to use the string manipulation functions. I also removed all error handling to clarify the actual algorithm. This code (with error checking) runs about twice as fast as the code above. As almost all time is spent in the reverseNum(), I believe the speed can be halved once again by calling it only once per iteration and cacheing the result.

function [n p] = pal196(in)
    n = 0;
    a = fix(in);
    while ~all(a == reverseNum(a))
        a = a + reverseNum(a);
        n = n+1;
    end    
end

function [ a ] = reverseNum( b )
    string = num2str( b );
    a = str2double(string(end:-1:1));
end