Guess any three-digit number (don’t tell me what it is).

Enter the three-digit number into a calculator, then enter the same three digits in the same sequence to create a six-digit number on the calculator display (e.g. if you guessed 472 as your three-digit number, the calculator will now display 472472).

Give me a moment while I use my powers of telepathy to determine your three-digit number.

>
>
>
>
>

OK, I now know the number you have chosen.

I have calculated that if you divide the calculator displayed six-figure number by 7, the result will be an integer value (with no decimals).

Further, if you now divide this result by 11, the number displayed will once again be an integer value (with no decimals).

Finally divide the displayed number by 13 – the calculator now displays the three-digit number you first thought of.

Are you impressed by my powers of telepathy or what?

 

OK, I now know the number you have chosen.

Oh really? I think you may be exaggerating a bit!

Cute trick though. It's eyebrow raising that the product of three primes produces ... this particular result.

 

Guess any three-digit number (don’t tell me what it is).

Enter the three-digit number into a calculator, then enter the same three digits in the same sequence to create a six-digit number on the calculator display (e.g. if you guessed 472 as your three-digit number, the calculator will now display 472472).

Give me a moment while I use my powers of telepathy to determine your three-digit number.

>
>
>
>
>

OK, I now know the number you have chosen.

I have calculated that if you divide the calculator displayed six-figure number by 7, the result will be an integer value (with no decimals).

Further, if you now divide this result by 11, the number displayed will once again be an integer value (with no decimals).

Finally divide the displayed number by 13 – the calculator now displays the three-digit number you first thought of.

Are you impressed by my powers of telepathy or what?

Not impressed at all.

If X is the 3 digit number, then the 6 digit number is

1000X + X = 1001X

But the prime factorization of 1001 is 7 * 11 * 13.

So this would be the same as me saying pick any number you want. Now multiply it by 6. I now magically determine that the result is both even and divisible by 3.

 

Oh really? I think you may be exaggerating a bit!

Cute trick though. It's eyebrow raising that the product of three primes produces ... this particular result.

Not too surprising. It's a case of there being lots of "interesting" numbers that could have been used, so it's not at all hard to find one.

For instance, we could have said pick a three digit number, double it, and tack on the original number. Now divide it by 2. Then by 23. Then by 29.

Or tack the original number onto the front of it instead and divide by 3, then 2, then 167.

Or pick a two digit number and make three copies -- so 42 because 424242. Now divide by 3, 7, 13, and 37.

 

Hi,

Not sure if i am impressed or not either, but the prime number mixture is cool.

For another example that is a LOT simpler...

Pick a three digit number XYZ and enter the number again to form XYZXYZ.
Next, divide by 1000 and press "Int" on the calculator. Your original number is now shown.

Another example that shows the simplicity...

PIck a three digit number XYZ and multiply it by 2.
Next, divide the number by 2 and that's what you entered originally.

Ok that was for poking fun a little, but more seriously if you want another sort of cool example then try this...

1. Start with a four digit number like 1234.
2. Now taking that number to be in HEX and not DECIMAL, convert it to decimal.
3. Repeat the above line six times, each time converting the number to decimal again and again (a total of six times).
4. Now taking your last result, convert it to hex six times, repeating using the result you get each time.
5. The result, if you converted right, will be again 1234.
Interestingly, you can do this with any number and you can convert it any number of times, as long as when you convert it back you do it the same number of times.
Also interesting is when you are converting to decimal, you ALWAYS must get a decimal number, and so when you are reversing the procedure even though you are constantly converting back to hex it's always a pure decimal number that NEVER contains the hex digits A, B, C, D, E, or F.

 

Here's one:

Choose two random numbers. Let's call the smallest one A and the largest B. Now perform the following steps at least ten times:

(1) Set the number C equal to B
(2) Add A to B
(3) Set A to C

Now multiply A times 3265 and then divide by B, rounding to the nearest integer. The answer is the current year.

 

Hi,

I guess that was a joke or something
Here is another quick one...

Pick any three digit number equal to 473.
Multiply by the square root of the day of month Easier falls on in the year 1795.
Divide by your age in minutes.
Your original number was 473

Here's a slightly more serious one not really a joke...

Pick any three digit number.
Multiply by your age in microseconds.
Divide by your age in microseconds.
How come you did not get your original number back?
(Note: this is serious and not that hard to figure out)

 

I guess that was a joke or something

Why do you say that?

 

Hi,

I guess that was a joke or something
Here is another quick one...

Pick any three digit number equal to 473.
Multiply by the square root of the day of month Easier falls on in the year 1795.

Does it work if I use the square of the day of the month Harder falls on in the year 5971 instead?

Here's a slightly more serious one not really a joke...

Pick any three digit number.
Multiply by your age in microseconds.
Divide by your age in microseconds.
How come you did not get your original number back?
(Note: this is serious and not that hard to figure out)

Because your age when you divide is not the same as your age when you multiply.

You can "break" and similar algorithm even if you use the standard "use your age" since someone could always claim that they did the first one just before their birth time and the second one just after.

 

Here's one:

Choose two random numbers. Let's call the smallest one A and the largest B. Now perform the following steps at least ten times:

(1) Set the number C equal to B
(2) Add A to B
(3) Set A to C

Now multiply A times 3265 and then divide by B, rounding to the nearest integer. The answer is the current year.

After the nth step, you have

A(n) = fib(n-1)·A(0) + fib(n)·B(0)
B(n) = fib(n)·A(0) + fib(n+1)·B(0)

where fib(n) = the nth Fibonacci number with fib(0) = 0 and fib(1) = 1 and, beyond that, fib(n) = fib(n-1) + fib(n-1)

These can be written as

A(n) = fib(n-1)·A(0) + [fib(n)/fib(n-1)]·fib(n-1)·B(0)
A(n) = fib(n-1)·[A(0) + fib(n)/fib(n-1)·B(0)]

B(n) = fib(n)·A(0) + [fib(n+1)/fib(n)]·fib(n)·B(0)
B(n) = fib(n)[A(0) + fib(n+1)/fib(n)·B(0)]

As n get's large, fib(n)/fib(n-1) approaches (1 + √5)/2, known as the Golden Ratio, which is ~1.6180. Let's call this ζ.

For sufficiently large n,

A(n) ≈ fib(n-1)·[A(0) + ζ·B(0)]
B(n) ≈ fib(n)[A(0) + ζ·B(0)]

3265·A(n)/B(n) ≈ 3265/ζ ≈ 2017.88

So it just has to be done enough times so that the ratio is close enough to the Golden Ratio in order for rounding to the nearest integer to pull it to 2018.

 

Ok that was for poking fun a little, but more seriously if you want another sort of cool example then try this...

1. Start with a four digit number like 1234.
2. Now taking that number to be in HEX and not DECIMAL, convert it to decimal.
3. Repeat the above line six times, each time converting the number to decimal again and again (a total of six times).
4. Now taking your last result, convert it to hex six times, repeating using the result you get each time.
5. The result, if you converted right, will be again 1234.
Interestingly, you can do this with any number and you can convert it any number of times, as long as when you convert it back you do it the same number of times.
Also interesting is when you are converting to decimal, you ALWAYS must get a decimal number, and so when you are reversing the procedure even though you are constantly converting back to hex it's always a pure decimal number that NEVER contains the hex digits A, B, C, D, E, or F.

I'm not sure what the interesting (which I interpret to mean unexpected or non-intuitive) thing is.

It seems like the only things involved here are that

(1) The decimal digits are a subset of the hex digits.
(2) When you convert to base-N you always get a base-N number.
(3) Performing a forward transformation n times followed by the inverse transformation n times is the identity function.

I don't see what is particularly "interesting" about any of those.

 

1. Make up a random N-digit number that is at least two digits long and that does not have all the same digits.
2. Make a second number by shuffling around the digits in the first.
3. Subtract the smaller of the two numbers from the larger.
4. Pick one of the non-zero digits in the difference.
5. Make a final number by shuffling all of the other digits (those not picked) in the difference.
6. Give the final number to a third party (the "puzzle master").
7. The third party will tell you the value of the digit you picked.

So let's say that I've done this and, in Step 6, give you the number 367263. What digit did I pick in Step 4?

Describe not only the algorithm, but WHY it works and also the reason for the various restrictions in the rules above (and which are necessary and which aren't)?

1) Why at least two digits?
2) Why can't the digits all be the same?
3) Why subtract the smaller form the larger?
4) Why pick a non-zero digit?

Can you think of a way to follow the rules but end up in a situation where the rules can't be followed?

 

1. Make up a random N-digit number that is at least two digits long and that does not have all the same digits.
2. Make a second number by shuffling around the digits in the first.
3. Subtract the smaller of the two numbers from the larger.
4. Pick one of the non-zero digits in the difference.
5. Make a final number by shuffling all of the other digits (those not picked) in the difference.
6. Give the final number to a third party (the "puzzle master").
7. The third party will tell you the value of the digit you picked.

So let's say that I've done this and, in Step 6, give you the number 367263. What digit did I pick in Step 4?

Describe not only the algorithm, but WHY it works and also the reason for the various restrictions in the rules above (and which are necessary and which aren't)?

1) Why at least two digits?
2) Why can't the digits all be the same?
3) Why subtract the smaller form the larger?
4) Why pick a non-zero digit?

Can you think of a way to follow the rules but end up in a situation where the rules can't be followed?

I really love this puzzle! It took me quite a while, but here's a [very] rough sketch of how it works:

First, define the function S(V) as the "recursive sum of the decimal digits of V". In C, this would look something like:

int S(int value)
{
    int result = 0;
    while(value > 0)
    {
        result += value % 10;
        value /= 10;
    }
    return result < 10 ? result : S(result);
}

If a given X and Y contain some permutation of the same digits then clearly S(X) = S(Y) [eg: S(951) = S(519) = 6]. And of course the absolute difference Δ = |S(X) - S(Y)| will be equal to zero.

Now consider the piecewise difference between successive digits of X and Y. If we make a list of these terms we find that the total sum is also equal to Δ. For example, (9 - 5 = 4) + (5 - 1 = 4) + (1 - 9 = -8) = Δ = 0.

This leads to the following general mapping rule, λ:

For any given X and Y, λ = S(X - Y) = 9 - Δ. [In this particular puzzle S(X) = S(Y) and thus λ is always 9 because Δ = 0.]

To recover the digit D removed from the digits of the absolute difference between X and Y, the S of the remaining digits is taken and subtracted from λ. However if the result is zero then D is either 9 or 0. But since we cannot distinguish between the two we have to disallow one or the other as a valid selection [which is why D has been given the constraint of being non-zero here].

In the given example we find that λ - S(367263) = 0 and so in this case D is equal to 9.

Not the most rigorous mathematical description of course (I'll leave that to the master ) but good enough to get across the general idea I hope.

 

You final approach is correct, but I don't see a reason for saying that λ = S(X - Y) = 9 - Δ. I don't see how it follows from the prior claims (which I completely agree with).

 

Why do you say that?

Hi,

Oh did i read it wrong perhaps? I'll re-read it after i reply here.

 

Does it work if I use the square of the day of the month Harder falls on in the year 5971 instead?



Because your age when you divide is not the same as your age when you multiply.

You can "break" and similar algorithm even if you use the standard "use your age" since someone could always claim that they did the first one just before their birth time and the second one just after.

Hi,

Yes, when you multiply your age in microseconds is bound to be different than when you divide because it takes some finite time to do the divide and thus you've aged a little bit more so the number cant come out the same.
I also assume you are not a fetus

 

You final approach is correct, but I don't see a reason for saying that λ = S(X - Y) = 9 - Δ. I don't see how it follows from the prior claims (which I completely agree with).

You're absolutely right, it doesn't really follow from anything other than heuristics - pretty much of like saying "I know this is true but I'm not sure why"! That's probably one of my biggest weaknesses in the mathematical arena, honestly. More of an intuitive thinker than anything else (in fact it took me much longer to write out that post than to actually solve the puzzle). I'll see if I can come up with a more solid line of reasoning though...I really do need to get better at that.

 

I'm not sure what the interesting (which I interpret to mean unexpected or non-intuitive) thing is.

It seems like the only things involved here are that

(1) The decimal digits are a subset of the hex digits.
(2) When you convert to base-N you always get a base-N number.
(3) Performing a forward transformation n times followed by the inverse transformation n times is the identity function.

I don't see what is particularly "interesting" about any of those.

Hello again,

What i thought was interesting is that this shows that there are some numbers, even very huge ones like with 100 digits, that when converted to hex multiple times, yields a number that does not contain any of the special hex characters A though F. Even taking a number with 100 digits and converting it just once to hex and getting a number that only contains only digits 0 thought 9 i think is interesting. Realize that this number could actually be 1000 digits long.
Example:
1658914123637105328114883634058238084229660743024 decimal
It is not apparent that this number can be converted to hex quite a few times and still retain only the digits 0 though 9.
If this number was transmitted through a medium and the first hex transformation turned up any digit that was A though F, we would know there was an error in the transmission.
If you are up to the task, you can find out the probability of a decimal number that when converted to hex still yields a number with only 0 through 9 in it, and then after two conversions, etc.
Note this is not intended though to be the greatest error detection scheme ever.

 

After the nth step, you have

A(n) = fib(n-1)·A(0) + fib(n)·B(0)
B(n) = fib(n)·A(0) + fib(n+1)·B(0)

where fib(n) = the nth Fibonacci number with fib(0) = 0 and fib(1) = 1 and, beyond that, fib(n) = fib(n-1) + fib(n-1)

These can be written as

A(n) = fib(n-1)·A(0) + [fib(n)/fib(n-1)]·fib(n-1)·B(0)
A(n) = fib(n-1)·[A(0) + fib(n)/fib(n-1)·B(0)]

B(n) = fib(n)·A(0) + [fib(n+1)/fib(n)]·fib(n)·B(0)
B(n) = fib(n)[A(0) + fib(n+1)/fib(n)·B(0)]

As n get's large, fib(n)/fib(n-1) approaches (1 + √5)/2, known as the Golden Ratio, which is ~1.6180. Let's call this ζ.

For sufficiently large n,

A(n) ≈ fib(n-1)·[A(0) + ζ·B(0)]
B(n) ≈ fib(n)[A(0) + ζ·B(0)]

3265·A(n)/B(n) ≈ 3265/ζ ≈ 2017.88

So it just has to be done enough times so that the ratio is close enough to the Golden Ratio in order for rounding to the nearest integer to pull it to 2018.

Just on a side note, you can construct an infinite number of puzzles based on an even more generalized principle.

Puzzlemaster:

(1) Choose two numbers, P and Q.
(2) Set R equal to the root of the polynomial x^2-Px-Q.
(3) Choose a target number T.
(4) Compute U as the product RT, rounded to the nearest integer.
(5) Determine the maximum number of iterations N needed to obtain a correct result. This value depends on two things, basically: the size of P and Q and the largest possible number that the user is allowed to choose from.

So for example:

(1) P = 3, Q = 2
(2) R = [positive root of](x^2-Px-Q = x^2-3x-2) = 3.5615528...
(3) T = 2018
(4) U = [rounded] RT = 7187
(5) N = 7 [Assuming that the user doesn't pick any numbers higher than say one million, this should be more than sufficient for the given P and Q]

Now the puzzle becomes:

Choose two random numbers. Let's call the smallest one A and the largest B. Now perform the following steps at least 7 times:

(1) Set the number C equal to B
(2) Set B equal to thrice B plus twice that of A
(3) Set A to C

Now multiply A times 7187 and then divide by B, rounding to the nearest integer. The answer is 2018.

 

Just on a side note, you can construct an infinite number of puzzles based on an even more generalized principle.

Puzzlemaster:

(1) Choose two numbers, P and Q.
(2) Set R equal to the root of the polynomial x^2-Px-Q.
(3) Choose a target number T.
(4) Compute U as the product RT, rounded to the nearest integer.
(5) Determine the maximum number of iterations N needed to obtain a correct result. This value depends on two things, basically: the size of P and Q and the largest possible number that the user is allowed to choose from.

So for example:

(1) P = 3, Q = 2
(2) R = [positive root of](x^2-Px-Q = x^2-3x-2) = 3.5615528...
(3) T = 2018
(4) U = [rounded] RT = 7187
(5) N = 7 [Assuming that the user doesn't pick any numbers higher than say one million, this should be more than sufficient for the given P and Q]

Now the puzzle becomes:

Choose two random numbers. Let's call the smallest one A and the largest B. Now perform the following steps at least 7 times:

(1) Set the number C equal to B
(2) Set B equal to thrice B plus twice that of A
(3) Set A to C

Now multiply A times 7187 and then divide by B, rounding to the nearest integer. The answer is 2018.

Hi again,

Oh ok i think i see why i thought this was a joke at first. I interpreted the current year to actually be the current year we are living in at the time. In other words, that would mean the algorithm (which is what these all are anyway) would have produced 2019 once we get to next year after January 1st, and 2020 on the following year, and 2021 next year after that, etc. So the fact that an algorithm could actually be sensitive to time itself seemed funny when there is no time data being inserted