As far as I can see, most (if not all) programs use the strategy to convert the square to a string, pad it with 0 if the length is not even, and split it in the middle.
This seems to work for the range of Kaprekar numbers in the given range [1..999]. However, when I tried to speed up my program by splitting in the middle, I found out a problem with 5292. It is a Kaprekar number:
But to recognize it, you have to split 2 and 6 of 8 digits.
The implicit assumption about the Kaprekar property to show up when the number is split in the middle seems to be wrong. I tested some Javascript programs of this challenge with 5292 and it is not recognized as Kaprekar number.
Dang, that's a great point. I should have made the OP more detailed to clarify that the "split" isn't always right down the middle — even if it happens to work in the [1...999] range.
I definitely didn't think of that possibly while creating the post, or while working on my personal solution.
What does your approach to this look like? Now you've got me curious about how you're going about solving it. NVM, now I see your other comment.
As far as I can see, most (if not all) programs use the strategy to convert the square to a string, pad it with 0 if the length is not even, and split it in the middle.
This seems to work for the range of Kaprekar numbers in the given range [1..999]. However, when I tried to speed up my program by splitting in the middle, I found out a problem with 5292. It is a Kaprekar number:
But to recognize it, you have to split 2 and 6 of 8 digits.
The implicit assumption about the Kaprekar property to show up when the number is split in the middle seems to be wrong. I tested some Javascript programs of this challenge with 5292 and it is not recognized as Kaprekar number.
Dang, that's a great point. I should have made the OP more detailed to clarify that the "split" isn't always right down the middle — even if it happens to work in the [1...999] range.
I definitely didn't think of that possibly while creating the post, or while working on my personal solution.
What does your approach to this look like? Now you've got me curious about how you're going about solving it.NVM, now I see your other comment.Is anyone interested in finding another 'strange' Kaprekar number like 5292?
I searched among the first 91 Kaprekar numbers in the range [ 1..108 ]. So far, 5252 is the only one you have to split asymmetrically.
What makes 5292 so special?
4879 is 'strange', too:
4879 = 238 + 04641
Ok, I see. I've missed it because of the leading zero in the second part.
I think your OP is really ok. I also didn't expect something like this. I think I will inspect some higher Kaprekar number.
But I am looking forward to see how the JS/Java/Clojure/LISP-like solutions get fixed (and I apologize for beeing such a killjoy ;-)