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.
2 Likes
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)
1 Like
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
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?
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).
1 Like
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.
1 Like
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.
Validator : All passed
Test : #6 Failed
[To comment from 2020, now, no french version available for this puzzle]