[Community Puzzle] Decode the message

[siminio]

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.

[Djoums]

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.

[dbaelz]

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

[dwarfie]

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

[siminio]

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.

[Djoums]

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.

[spyr01d]

All test are OK except Validator 4.

[TwoSteps]

Validator 4:

Input:

117
1234567890

Output:

811

Good luck!

[Null_A]

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)

[andHW]

I don’t think is related to Cryptography…

[YuvalG]

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.

[anon72424297]

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…

[user21539]

Hello,

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

[5DN1L]

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

[jddingemanse]

It was described earlier (by @Null_A and @YuvalG), and claimed by @anon72424297 not to be a bug - but I still do not understand it: my code fails Test 6, but passes all else (including Validators). In any case, there is imbalance between test and validator, since Validator 6 is not covering the issue tested in Test 6.

• Maybe someone can look to my published code and explain what detail I overlooked for Test 6?

[5DN1L]

Try running your code with C = “H_eo: Wrld!” (i.e. the same string as in Test 6), and P from 0 to 132. You’ll notice that your code produces the wrong answer when P = 121 to P = 131 (and the answer becomes wrong again when P = 242 etc).

[jddingemanse]

@5DN1L

Try running your code with C = “H_eo: Wrld!” (i.e. the same string as in Test 6), and P from 0 to 132. You’ll notice that your code produces the wrong answer when P = 121 to P = 131 (and the answer becomes wrong again when P = 242 etc).

Hah the same goes wrong with Test 3 C=‘ABeDFC’ and P=36 (and further), or even C=‘ABC’ and P=9 (in the latter, my code gives ‘ACA’ for P=9 while it should be ‘AC’. I’d say that this is a pretty big mistake in my code that apparently is not covered in the Validators and only accidentally in Test 6. My code mishandles the final range of switching to an additional ‘digit’. I think my code counts similar to the numerical system 0…9 → 10 … 99 → 100 … 999 while it is required to count like 0 …9 → 00 … 99 → 000 … 999 for this contribution.

[5DN1L]

Yes, that’s exactly the issue

One of the approvers mentioned “off-by-one errors” when they tried to solve the puzzle (and I assume that’s the same issue you had faced earlier). While the approver was able to identify and fix the error in their own code, the author and the approver didn’t realise the need to include a case which could trigger such errors in a validator. What a pity.

[Askari]

Validator : All passed

Test : #6 Failed

[To comment from 2020, now, no french version available for this puzzle]