4-digit trick, predicting a final number

[checkitagain]

Ask someone to pick 4 digits, but not all of them be the same.

Zeroes are allowed as digits

Form the largest number possible and the smallest number
possible, including annexing any 0-digits to the left,
Subtract the smaller number from the larger number,
Write the difference as a 4-digit number, with any zeroes
written on the left as part of the difference. Then,
again, form the largest number and the smallest numbers
possible, respectively, and subtract them. Repeat the
process as above.

Keep repeating this process until the resulting number
doesn't change anymore.



Then tell the person that their final number they end up

with is 6174.


Example:

The person chooses 0, 0, 0, and 1.


1000
-0001
------
0999


Then:

9990
-0999
------
8991



And then the person who chose the digits would continue
in this manner until one unchanging number is reached...

 

[dodo]

until one unchanging number is reached...

Is it?
The very example you give of 999 seems to fall into a loop:

9990 - 0999 = 8991
8991 - 1998 = 6993
6993 - 3996 = 2997
7992 - 2997 = 4995
5994 - 4995 = 999
9990 - 0999 = 8991
...

Edit: quick computer search on all 4-digit numbers (in this case, including numbers with all digits the same, palindromes, etc. - all numbers from 0000 to 9999):

206 cases end with the loop ['0000']
704 cases end with the loop ['8712', '6534']
1594 cases end with the loop ['9090', '8181', '6363', '7272', '5454']
3748 cases end with the loop ['0900', '0810', '0630', '0720', '0540']
3748 cases end with the loop ['9990', '8991', '6993', '7992', '5994']

 

[checkitagain]

Is it?
The very example you give of 999 seems to fall into a loop:

9990 - 0999 = 8991

8991 - 1998 = 6993 . . . . . This should be 9981 - 1899, and the other corrections
would be similar to this.


6993 - 3996 = 2997

7992 - 2997 = 4995

5994 - 4995 = 999

9990 - 0999 = 8991
...

Form the largest number possible and the smallest number
possible, including annexing any 0-digits to the left,...

No, for each subtraction, the first number must be composed
of nonincreasing digits and the second number must be composed
of nondecreasing digits.

 

[dodo]

Ahhh, sorry. So you sort the digits down, then up, and subtract.

I repeated the experiment, this time obtaining:
10 cases end with the loop ['0000'] (presumably, the all-digits-equal cases)
9990 cases end with the loop ['7641']

I was curious about how long it takes to reach the fixed number, and got this, for the above 9990 cases:
24 cases took 0 steps (presumably, the 4! permutations of '6174')
648 cases took 1 step
1008 cases took 2 steps
2184 cases took 3 steps
1152 cases took 4 steps
1830 cases took 5 steps
2064 cases took 6 steps
1080 cases took 7 steps

But the question, of course, is *why* does it always end with 6174.

Edit: removed comment about no other permutation of 6174 being reached first. Program bug, sorry.

Edit 2: Hand-made diagram (hopefully correct) of the sorted differences.
Edit 3: Working with 3 digits only, the situation is far more simple.

 

[micromass]

Ahhh, sorry. So you sort the digits down, then up, and subtract.

I repeated the experiment, this time obtaining:
10 cases end with the loop ['0000'] (presumably, the all-digits-equal cases)
9990 cases end with the loop ['7641']

I was curious about how long it takes to reach the fixed number, and got this, for the above 9990 cases:
24 cases took 0 steps (presumably, the 4! permutations of '6174')
648 cases took 1 step
1008 cases took 2 steps
2184 cases took 3 steps
1152 cases took 4 steps
1830 cases took 5 steps
2064 cases took 6 steps
1080 cases took 7 steps

But the question, of course, is *why* does it always end with 6174.

Edit: removed comment about no other permutation of 6174 being reached first. Program bug, sorry.

Edit 2: Hand-made diagram (hopefully correct) of the sorted differences.
Edit 3: Working with 3 digits only, the situation is far more simple.

Nice Dodo!

Could you perhaps do the same with 5 digits and 6 digits and see if they also end in the same number??

 

[dodo]

If I'm not mistaken, they don't. Pity that there is not a general rule to be found.

With 5 digits, you can end up with 99954, 98622, 98532, 97731, 97641, 97533, 97443, 96642, 96543 or 95553 (or 00000).

With 6 digits, you end on 995544, 886320, 876420, 875430, 875421, 866322, 885420, 766431 or 665442 (or 000000).

With an odd number of digits, I guess you are bound to end always on a number containing a 9, because the middle digit is the same when sorting up or down...

With 2 digits the situation is easier to understand. The difference of a number minus its reverse is a multiple of 9, and there are only so many possibilities; they happen to lie in a circle, 90 -> 81 -> 63 -> 72 -> 54 -> 90.

 

[micromass]

Here is a nice graph:

More information at: http://en.wikipedia.org/wiki/6174_(number)

 

[dodo]

Ah, nice, Micromass, thanks for the reference (:shame: I forgot to look up Wikipedia).

This problem sounds like a remote cousin of the 3n+1 conjecture, doesn't it? (BTW, I don't have at hand Guy's "Unsolved problems", but I wonder if someone can check if Kaprekar's process is mentioned there, and related to something else. Or maybe is not as much "unsolved" as to merit being there.)

 

[micromass]

Ah, nice, Micromass, thanks for the reference (:shame: I forgot to look up Wikipedia).

This problem sounds like a remote cousin of the 3n+1 conjecture, doesn't it?

It sure does. The level of difficulties involved to prove something meaningful seems the same.