[Community Puzzle] Decode the message

I have the same problem.
All my tests in the IDE pass but not the sixth test in the validators.

I think a test should be added in the IDE to be able to find the problem.

I’ve sent the validator to both of you, can you tell me what was the problem ? Seems like it’s common to fail on it.

With Kotlin the test 6 and 7 failed for me as well. I identified a possible problem with both tests: The input P is to big for an (32 bit) integer and therefore it throws an exception on parsing it into an integer.

I’ll might change my implementation today to use the Java BigInteger class or Long to store the input. But it makes the code more complex and it isn’t that “easy” (in terms of the difficulty shown) anymore.

By the way: I liked the puzzle. Gave me something to think and was very interesting :slight_smile:

It was asked to creator to fix the stub from int to long many times …
Looks like it is too complicated for him (or he doesn’t care) so i did it myself

Now it’s fine I finished the puzzle.

To explain you the problem I had I am gonna give you a simple example.
encoded = 974
alphabet = “H_eo: Wrld!”

The length of the alphabet is 11. So what I do is:
974 / 11 * 11 = 968
6/ 11 = 0 (so index -1 and therefore an error)
6 / 1 = 6 (so index because it’s last element)

While the encoded message was built this way:
121 * 7 = 847
11 * (10 + 1) = 121
1 * 7 = 7 (6 because it’s the last element)

So when there is a string with a latest letter in the alphabet it was producing an error in some cases.

1 Like

Thanks for the feeback, that offset by 1 was intended actually.
I’ll swap the test and validator 6 so people have a chance to understand what’s going on.

All test are OK except Validator 4.

Validator 4:




Good luck!

After analysis, I think the problem encountered in test 6 is indeed a bug.
p = 34170657950616
c = ‘H_eo: Wrld!’
result = 'Hello! World ’
In the system described, the last letter of the alphabet cannot be used by indicating the offset of the last character, otherwise the latter interferes with the following character (construction from right to left). We can correct this problem by using offset 0 for the last character, this does not stop the problem in the rest of the logic, we just have to deal with the case of offset 0 in the code (it must return the last character ). In this case the code must be 34170638463445 (which uses 0 for the ‘!’) And not 34170657950616 (which uses 11)

I don’t think is related to Cryptography…

Same here.
There’s a bug in test case 6, with
p=34170657950616 , c=“H_eo: Wrld!”
i’m getting “Hello !WWorld”.
And with p=34170638463445, as you mentioned, and with the same c i’m getting
“Hello ! World”

No problem with the other test cases and validators.

There’s indeed a bug… but in your code.
The test can’t be ‘bugged’ since it consist as nothing more than the given input/output values. And more than 500 users (including me) have a fully working code, simply following what’s said in the statement.
So you better read the statement again, and check back your code…


The encoding scheme instructions are a bit unclear to me. I can’t tell if I am supposed to go through all combinations until I’ve computed the guess at index p (test 1 seems to indicate this), or if it is some other encoding scheme that I’ve gotten completely wrong (like dividing the number by alphabet size, and somehow ending up at the correct encoding)?

The instructions mention “hello” being encoded as 7073801. So I suspect it is because “hello” is the 7073801’th combination with that alphabet?

I’ve just begun here, but this is the first puzzle that has had me this stumped :joy:

Your interpretation of the “hello” example is correct. And while you can go through the combinations one by one to reach the answer, there are more efficient ways to calculate it.

Also, don’t assume there must be a single correct approach to a problem. There are often multiple ways :wink:

1 Like