The pit and the Pentium logic - solution

[gadf]

Since Nefarious Ned does not operate both traps simultaneously, one should look for a number x that generates the same number in the second row i.e. x=y

The computer counts how many times each digit appears in x and type it in its place in y (the places are 0123456789). For example , if x=1223334444 then 0 don't appear 0 times, 1 appears 1 time, 2 appears 2 times, 3 appears 3 times, 4 4 times and the rest zero times therefore we obtain y=0123400000

there is at least one possibility to generate the same number: remembering the there are only nine digits 10=0 therefore x=0000000000
will generate y=0000000000 and therefore will
open the door safely

[ralphmerridew]

I think the intended answer is 6210001000. However, I think there may be other answers, where A->B->C->A, unless the only other cycle is (6300000100, 7101001000).

[mith]

well, so much for part 2. :P

i haven't figured out if there are 3 member cycles or not yet. (haven't really bothered looking)

[ralphmerridew]

What was part 2?

[mith]

whether there are any 3 cycles.

[/dev/joe]

Some more solutions.

Since the computer only displays one digit in each position, what happens when you punch in 10 of the same digit?
I would expect the computer to roll over and the extra digit is lost (or moved to the left, if it wasn't the leftmost).

So punch in 0000000000.
There are 10 0's and 0 of everything else, so the computer returns... 0000000000.

Also, since the relationship is required to go both ways, any code which yields a safe code as its output is also safe. Thus, not only is 6210001000 safe, but so is any rearrangement of those digits, and therefore, any code consisting of 6 of one digit, 2 of another digit, and two other digits once each is also safe.

One such code is 5212000000, so all codes consisting of five of a digit, two each of two different digits, and one other digit is also safe.

One such code is 3321100000, so all codes consisting of three each of two different digits, one digit twice, and two digits once each is also safe.

[mith]

ah, good, i was wondering if anyone would notice that

now the question is, is there any code that *isn't* safe?

btw, i was going to write in the solution something that got rid of the 0000000000 case, as it isn't very interesting.

[extropalopakettle]

Lately the smart people all seem to be unregistered.

[mole]

Wouldn't ralphmerridew's (6300000100, 7101001000) count as unsafe codes?

[mith]

yeah, they would. i didn't really mean there aren't any at all, i just think there's quite a few safe ones.

[ralphmerridew]

Well, the two codes I gave are not necessarily safe; it is possible that every code happens to be safe. Additionally, three of the trial codes used in the example lead to that pair, so are NNS, while the fourth leads to the self-producing code.

[CrystyB]

LOL @ mith's reply 4!

PS Mole, what did you mean they are not safe? I think i can still count...

Edit: Ow i get it. Since the two numbers only cycle through themselves, they can still be unsafe, if one opens the poison trap and the other opens the other trap...

[This message has been edited by CrystyB (edited 07-19-2002 07:38 PM).]

[ralphmerridew]

Hey, mith, are you sure pt 2 is supposed to be whether there are any 3 cycles? How did I clear that question up?

[start pilot]

If you take the sum of all digits in y, one finds always 10. Coincidence ?

[ralphmerridew]

No, it's not a coincidence. sum of digits in y = (#0s in x) + (#1s in x) + (#2s in x) + ... (#9s in x) = 10.

With the exception that if you enter all digits the same (for example, 7777777777), then it may overflow to 0000001000, 0000000000, or (0)(0)(0)(0)(0)(0)(0)(10)(0)(0).

[pierrecurie]

I think we just need to know the number that when pushed in, returns the same number.

[El Blobbo revived]

0000000000 might give 0000000001

[Jen Aside]

000000000A?

[El Blobbo revived]

A000000000!

[This message has been edited by El Blobbo revived (edited 01-19-2002 05:14 PM).]

[luckyscotty]

Has anyone noticed that the y value that is given by the computer always adds up to 10?

This sort of contradicts the solution being 000000000? Am I right or does someone have another theory?

[El Blobbo revived]

I'm confused. The answer logically cannot permutate, but it must have a "non-reiterative" digital root of ten, and must equal itself when subjected to the function.

[This message has been edited by El Blobbo revived (edited 01-21-2002 08:16 AM).]

[pierrecurie]

Yes I have noticed that the sum of the digits must equal 10.

[pierrecurie]

It doesn't seem right. The last clue doesn't fit the idea of the output number telling us how many of each number there are in the original.

[Top Gun]

There are definitely no 3 part circular references.

All numbers entered will either resolve (eventually) into 6300000100/7101001000 or 6210001000 or 0000000000.

Most numbers resolve into 6300000100/7101001000 and are therefore NOT safe.

Numbers that resolve into 6210001000 or 0000000000 are SAFE.

There are 3,628,810 possible numbers that resolve into 0000000000. That is; 10! + 10. That is; the number of combinations of 1 of each digit (eg. 0123456789->1111111111->0000000000) plus the number of combinations of ten identical digits (eg. 9999999999->0000000000).

A number will resolve into 6210001000 if, after the initial calculation, you end up with one of the following strings of digits, with the digits in any combination:

6211000000
5311000000
5221000000
5211100000
4311100000
3222100000
3211111000
4221100000
3321100000

All that is left to do is to calculate how many source numbers that covers. I would estimate that around a quarter of possible numbers will end up being safe. Not bad odds.

[Jen Aside]

quote:

---

Has anyone noticed that the y value that is given by the computer always adds up to 10?
This sort of contradicts the solution being 000000000? Am I right or does someone have another theory?

---

You're confusing "so far" with "always"... If I gave a function X where f(x) for 1, 2, 6, and 10 all gave the answer "3", would you say that for all f(x) = 3? I could disprove (not "seemingly contradict") your statement by saying f(4) = 4 or f(7) = 5, if the function X basically returns the number of letters in the (English) name of the integer entered.

[CrystyB]

pierrecurie

[neweyes]

I would type an "x" number, leave my fingers on the buttons control & z for possible immediate use, pray, then reach my pinkie over to compute to receive a "y" response.

[neweyes]

... or maybe just get poised ready to compute one more time. And hold my breath. And grab the door knob.

[Tadeusz Dobrowiecki]

Hello,

Of course I know that it is not really int the spirit of the
puzzle, but what if the poor fellow in that room enters
x = 6210001000 into the computer and gets y = 6210001001
instead. Because the "true" rule is something like:

z = digit counting of(x);
if z =/= x then y = z else y = z+1;

There is no MUST for the computer to stick to the proposed solution,
isn't it? And that brings two issues into mind.

Due to the fact that the fellow has no second chance if he goes for
the door, he shoudn't stop at the fourth example. He should try them
as many as possible. In here the puzzle is unusual (not entirely honest?),
because the fellow in the puzzle can obtain more information than the
solver.

Formally the puzzle is the problem of finding a general relatioship
y = f(x), hopefully (but not for sure) possessing a fix-point x = f(x) solution,
based on 4 examples, i.e. it is an inductive learning problem with a bias.
As such it cannot be solved with certainty, only if the number of examples
to test the hypothesis will grow, or we will be lucky. Without checking
out that 6210001000 on the computer for real, we still cannot be sure!

Regards

Tadeusz