That's a very nice test-map.
I run a 10^6 simulations of a try-random-move-from-options-at-any-point solver and it finds the solution roughly once in 4000 attempts.

It helped me avoid trying a lot of bad heuristics, and to find a relatively elegant approach to the puzzle.

I don't have an idea for an algorithm that would be significantly faster than a naive solution.

if you do then go ahead and create a performance version :)

These boards aren't isomorphic:

• first board has 3h that is the only heart on board
• the second board has 3c and 8c.

So the hearts on the first board aren't isomorphic to any suit on the second board

Thanks!

2. I have fixed the missing suits for the example

3. This is mentioned in the problem description. I have added the fixed tests for this example (there was one actually - that tested full deck of cards in two different orders, but I added some better examples to the flop section.

Thank you. This comment saved me a lot of time!

Fixed also in the sample tests.

I would love to hear other's opinion before fixing anything as I don't agree with your opinion.

In the input description is says that :"All coordinates and dimensions are integers."

So I think that indicates that it could be any integers (positive, negative, large, small) and the is not expected to take in way an advantage of it being some limited range.

Fixed

I have republished the Kata and after fixing the major flaw in the tests all solutions published in so far have been invalidated. Sorry for that.

Marking issue as resolved.

OMG.
There was a bug in a testing loop.

  if expected is not actual:
      test.assert_equals(actual, expected, f"For point ({x} {y})")
      return

This code was intended to fail only one assertion per test case.
But the outside loop tested for sameness while the assertion inside tested for equality, so the solution that returned identical rectangle instead of the same rectangle got assertion right, and then early return - performing only one instead of large numbers of checks beating thus beating the tests.

• Removed blank line
• Flipped expected and actual

I don't understand the comment about buffer overflow. Can you elaborate?
(Edit: I understand now, fixed as well)

I've made initialy performance requirements relatively close to the reference solution.
If it proves to be too tight (as in people with good algs getting timeouts) I'd like to reduce them.

Very nice puzzle!

Cool problem, but I was kind of disappointed that ALL solutions seem to be hardcoding the result.

I suggest an idea to prevent hardcoding:

Require the solution to calculate number of possible seqeunces for any starting sub-sequence - not just one starting character. So instead of ("C", 7) input would be ("ABG", 12).