That sure isn’t embarrassing. Why do you say something like that?
How do you know it was a validator in the description?
One may check the details of validators in the Contributions view, i.e. the view where one can comment on, approve or reject clashes and puzzles.
Validators are supposed to be hidden for preventing hardcoding solutions, so it is definitely not a good idea that a validator is the same as a test, and by the same logic, it is also not a good idea that a validator is shown as part of a puzzle statement.
Anyone reading the contribution before it was approved and published could see the validators.
This thread was started on October 16th. So I guess the puzzle was already approved. It was probably no longer under contributions.
The validators were hidden at that point.
So how would anyone know that a validator was in an example in the puzzle description? Besides those who were really interested in the validators in the contribution view.
Also, quoted from https://www.codingame.com/playgrounds/40701/help-center/approval-process:
Editor right: editors have approver rights. Editors can also edit approved contributions.
Any player whose level is greater or equals to 29 has editor rights.
I have a level greater than 29, hence I have access to the validators of all text-based puzzles, both before and after approval.
Hi,
Code read again, I don’t see my mistake. Please, could some one give me another test 8, closer to validator 8 ?
Thx,
Are you able to create custom tests based on my last reply to you? It should not be that difficult to create one by yourself.
all rewritten and it’s ok, thx for the help
merci b0n5a1,
ton jeu d’essai m’a permis de trouver l’erreur qui subsistait dans le test 4.
thank you b0n5a1,
your test set allowed me to find the error that remained in test 4.
Same situation, everything fine until validator 8. I had to put Codingame in expert mode to have custom test cases and build a shuffled one from the 8th test case.
@pardouin said that a proper cycle detection is not needed, but that’s not exactly true, you need a little somewhat evolved loop checking because it is not sufficient to rely on the fact that the first and last char of the replacement are already known (the change in ordering invalidates this hypothesis).
My solution fails for validator 6. Anyone have a custom testcase I can use to find the error in my code?
Validator 6 is similar to Test 6: there is one pair of conflicting instructions. If your code can identify the pair and output “ERROR”, you pass that validator.
Don’t know why but wrote my check more strict and now it works also for the validator. Thanks!
1 Like
I found the validators and was able to figure out the difference. Hope it helps others in the future who have the same issue (only validator 6 is failing, while all tests and other validators are ok). You can try this test case, which is slightly different than test case 6:
zo zi tw ax
5
ioerc
zizhm
asrfb
tuoge
urebe
The puzzle states we should detect the instructions are incorrect, which includes they have cycles.
However I managed pass the tests without checking for cycles, like follows:
If any string still changes at any point during the (N+1)th application of the N rules, I decide there is a cycle and return “ERROR”.
If your goal is to test the code tests for cycles you should create a cycle with input that does not go inside it.
For example make a test like Test 4 (with cycle z→i→a→z), but only use strings without the letters z, i, a.
Using simulation (“(N+1)th application of the N rules”) to detect cycles is acceptable. It’s still a form of cycle detection, and the statement doesn’t mandate a particular detection method.
The problem’s intent seems to be (for the first step) to identify cycles within the replacement rules themselves, regardless of whether those cycles actually affect the transformation of the input strings. In other words, the input strings don’t matter in such cases, so having additional test cases might not be necessary.
This simplified test does not detect cycles if they do not apply anywhere on the input.
If the intent was to detect cycles, it is defeated. This is why I was asking…
Ah I see what you meant now. I thought you meant simulating using a custom string instead of the given string.
I’ll take a look and decide if I should add cases to the puzzle.
I’m leaning against adding test cases for transformation rules that contain cycles but aren’t applicable to the input strings because:
-
Excluding such test cases would allow players to use the alternative approach you mentioned (simulating the rules with the input strings), rather than being confined to the single approach of cycle detection.
-
Once contributions are approved, they should remain largely unchanged, except for very minor fixes or very significant issues. Introducing the said test cases would require rewriting the statement to clarify the additional scenario, which is outside the scope of minor fixes or very significant issues.