How to fix "Validate Sudoku with size `NxN`"

[hobovsky]

Follow-up on #171

Kata: Validate Sudoku with size NxN

• 4 kyu
• A bit generalized version with allowed sizes other than 9x9
• 85% with ~7.3k completions
• 15 pending issues
• 6 languages + 9 pending translations
• Published Sep 2014

"Sudoku validator" kata for 9x9 boards got retired and replaced by a new kata Sudoku board validator. Some reasoning why the NxN version was kept is presented in #171 , and in discourse of the new kata. However, now we need to decide how to proceed with it. Some (but not only) possibilities are:

• Fix Validate Sudoku with size NxN by plugging holes in tests and potentially removing annoyances like cells with incorrect types, invalid sizes (rectangular or jagged), etc. I have no good idea how to generate large boards, especially for negative cases, but Scala translation reportedly does this. The potential problem is that this way the kata keeps it arguably too high 4 kyu rank.
• To make the kata live to its rank, add some additional challenge to it: maybe make it a code golf or add some kind of restrictions? Maybe there would be some good idea for enforcing performance requirements?
• If the existing kata would be deemed unsalvageable, too difficult to fix, or severely overranked, we could try something similar as with the 9x9 ones: retire it, and replace with a new one, going through regular beta process. However, I would expect at least a few "close duplicate/very similar to the 9x9 version" votes. Maybe try to disguise it as something else, for example "Latin squares with additional constraint of 'small boxes'"?

Any ideas how to proceed with the kata are welcome.

[Blind4Basics]

considering the mess it currently is, and the number of languages (whose tests content are different from each others anyway), I'd opt for way 3. Thoughts:

• your new version can be used as a strong base to build the new test suite (adding something to handle the NxN aspect)
• it still would require some kind of twist to avoid it being too close to the 9x9 thing, yes.
  • golfing isn't a good idea imo (not actually translatable)
  • perf constraint: maybe, but the test generation will most likely be slower than the tested logic => hard to set up properly (would require mutations of a set of boards to gain time. A pain to implement for very little gain, I guess, especially considering that the 9x9 holds the "correct" efficient approach in multiple solutions)
  • changing the input type to plain strings might effectively do a good part of the trick (allows regexp approaches as well, might be fun (!?) )
  • going that way, an alphabet could be provided as second argument, maybe? (not sure that's a good idea, just a random thought)

[Kacarott]

Some ways NxN could be made harder:

• Make the input a generator of generators. Solutions must work lazily otherwise timeout
• Make it N**3 instead of NxN

[Blind4Basics]

I like the NxNxN... could actually lead to a N**N version... That would definitely be different enough. But the test generation might be beyond doable/reasonable.

[hobovsky]

I like the ideas of custom alphabet, and of 3D cubes (even tho I've never heard of 3D-oku, and I have no idea what are criteria of validity of such cube).

[Blind4Basics]

mmmh... Good question... XD Some conventions could be found, but I'm not even sure that's doable.

(x,y,z), would need to check:

• lines on x (size N)
• lines on y (size N)
• lines on z (size N)
• squares sqrt(N)**2 on each plane
• and cubes of cbrt(N)**3!?? na, cubes of sqrt(N)**3, rather?, na not working. back to square 1 (or just ignore that rule)

(is that even possible to generate FIND valid inputs for the tests...?)