It'd look like the 2nd way benefits performant solutions way more than 1st way, so I'd go for that. It also probably makes worse case scenarios more demanding on performance, which might or might not be a good thing.

I figured out two ways to enhance the random tests:

1. Simply increase the number of maximal random tests from 200 to 1000.

2. Increase the number of pixels (up to 4900) and territories (up to 180) while keeping the number of random tests the same.

Here are the test results:

Which one do you prefer? :)

The problem is, the description specifies

There are about 50 fixed tests and 1000 random tests

a large map in random tests could have 2,500 pixels

All tests will have no more than 90 territories

In the worst case specified by the description, with the first input run 1000 times, every solution will time out. But the solutions aren't actually timing out in practice because the actual tests are softer: there are only 200 tests of maximum range. With this the solutions take 3-6 seconds to finish the tests.

So at the very least, the test size needs to be further restricted to better reflect the actual performance required.

chai and assert should be used.

at least one of the inputs times out all these solutions

I just tried the author's solution and my solution manually on my local environment and cw server, and neither of them timed out.

Could you double check or provide another example? 🤔

Every existing solution (including author solution), except one, can't actually solve the kata under the worst bounds: at least one of the inputs

!!!!!!!!!!!!!!!!!!!!!!
#%&()*+,-./0123456789:
!!!!!!!!!!!!!!!!!!!!!!
;<=>?@ABCDEFGHIJKLMNOP
!!!!!!!!!!!!!!!!!!!!!!
QRSTUVWXYZ[]^_abcdefgh
!!!!!!!!!!!!!!!!!!!!!!
ijklmnopqrstuvwxyz{|}$

!!!!!!!!!!!!!!!!!!!!!!
##%%&&(())**++,,--..//
0112233445566778899::0
!!!!!!!!!!!!!!!!!!!!!!
;;<<==>>??@@AABBCCDDEE
FGGHHIIJJKKLLMMNNOOPPF
!!!!!!!!!!!!!!!!!!!!!!
QQRRSSTTUUVVWWXXYYZZ[[
]^^__aabbccddeeffgghh]
!!!!!!!!!!!!!!!!!!!!!!
iijjkkllmmnnooppqqrrss
tuuvvwwxxyyzz{{||}}$$t

times out all these solutions, so clearly there needs to be more tests of maximal planar graphs. Also:

There are about 50 fixed tests and 1000 random tests

There are actually 1200 random tests. Since you do get to decide how many random tests to run, this should be an exact number, and definitely not an under-estimate.

The cheese mentioned below still works, after hardcoding all the fixed tests.

Leading and trailing newlines are inconsistent through the test cases; sometimes there are leading newline and sometimes not.

Isn't [23, 79, 86, 87, 88, 96, 151, 215] the exact case #215 on this site? Why it isn't foldable? 🤔

You a gravedigger now? This comment is 3 years old! :D

You don't need any knowledge about this type of problem to be able to solve it. The 2 kyu (beta) version does require more in depth investigation into the domain.

I used R graphics to visualize what my own solution was doing, and to make the images that appear in the kata description.

As a hint at the time I solved this, the console output is not sanitized, so you can output SVG graphics to both see the input and verify your output.

Fixed it :D
Now you have to return None in such cases