i had quite some fun with this puzzle.
one thing i like about this puzzle is that it is easy understand and easy to solve intuitively but hard to implement in code. let me elaborate that a bit: it is easy (i find it easy) to intuitively deduce where the squares are and in what order they were drawn. but it is hard (i find it hard) to put all those intuitive deducing in code so that it can be solved programmatically.
it took me some time but i have managed to write code that can solve all the test cases. but … do not solve the validators.
i was wary of this because i already have experience with codingame puzzles that have lacking description and validators that cover cases which the tests do not.
i applaud the ellegance of the puzzle description that is described in only three sentences. but i find it upsetting that practically no limitations or guarantees are given in the description. for example: is there always at least one corner visible? is there always at least one character visible at all from the square?
in all test cases there is always at least one corner that is unambiguously identifiable for every square. the description is silent whether this is a guarantee or not. i wrote my code as if that was a guarantee. it seems it is not guaranteed.
i know that we should not “hardcode” our solution. i understand the need to have validators that are “secret”. but i do not see that necessity to withhold test cases that cover all the edge cases that the validators cover. because you just need to change sizes or flip or turn the input to prevent hardcoding.
i had fun trying to understand the problem description. i had fun trying to formalize the deductions i did when i solved the puzzle intuitively. i had fun writing the code and designing a data structure that fits the algorithm nicely.
but now i have to code against a black box (validators). and that does not feel as much fun. because i have no limitations or guarantees that i can hold. it seems that i have to code a backtracker which just brute forces over all possible square sizes and positions. my current code feels much more elegant than a brute force backtracker.
my plea to the designes of this puzzle (and to all puzzle designers in codingame) is to add test cases that cover all the possible edge cases that the validators cover. so if a validator has no unambiguously identifiable corner for a square then also write a test case with the same condition (but different sizes or whatever).
i know i can write my own test cases. and some people in this thread were very generous writing test cases for all kind of edge cases. but the workflow for custom edge cases is quite lacking. i need to paste input and output separately. i can only have one custom test case at a time. i cannot save them. i cannot run them all with one button.
also writing a test case is hard. more so if you have not 100% confidence in your code. did it fail because error in code or because of error in test case?
i know (i believe) that the puzzle designer are also volunteers. so it is wrong for me to demand anything. that is why this is a plea and not a demand. i am grateful for codingame platform and i am grateful for many fun puzzles.
thank you for the fun puzzle. please write test cases that cover all the edge cases of the validators. or at least state the guarantees (or lack of) in the puzzle description.
