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 
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:
Input:
117
1234567890
Output:
811
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ā¦
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 
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 
1 Like