In the description, Features of random tests section:

every cell in the the grid will always be populated by positive integers between 1 and 5

Typo there (double the).

Oh, I was just playing with tests, you can choose different ranges. I just wanted to have consistent results, that's why I limited the value to 10 or 11.
Using sets helps for merging in this case, yes, but also checking if an element is included in a set is O(1), while checking if an element is included in a list is O(n).
You can read here more about time complexities in python (that's how I learned as well at the beginning): https://wiki.python.org/moin/TimeComplexity

Thanks for this, pretty helpful - the logic of using sets seems pretty convienient - I'm assuming this is just to make the merging logic much nicer by allowing us to use a union, but correct me if there are other benefits to this. Only thing is it doesn't seem substantially faster to run, is just changing the length of the grid that can be generated as an input to a more limited range fine (I'm assuming so since this isn't a performance Kata)? Or should I use a different internal solution to allow for larger grids to be used?

Just quickly replying to say I haven't forgotten about this - will get to it today. Was exhausted and really needed the weekend off - sorry for lack of transparency

1. It is much better now ;)
2. I am pretty sure you'll be given permission if you ask powerusers. Anyway, you can of course take my solution...

Edited my description to hopefully be a bit nicer - let me know if it's better now. Also pumped the number of random tests up to 500 - increasing the grid size might take a bit of work, but I'll give it a shot tomorrow if necessary

Heya, thanks for the feedback. I'll edit the description to change these.

It's a little embarassing but the main reason the tests limit the size of the grid is because my own solution is inefficient (even the algorithm is a bit of a self-figured out thing using a tiny bit of cleverness) - I came across this problem in a project where the grid was of limited size and calculated infrequently and so I had to worry less about performance, and based my solution code off that. I'd also not be too keen on making it a question of performance when my own code fails on this front, and thought these numbers were sufficient to prevent guesswork.

I do fully understand and agree with what you're saying however, so I will have a shot at refactoring tomorrow (it's too late to focus here right now) to see if I can cut out any inefficiencies (potentially using any solutions I'm given permission to cross-reference if it's acceptable - don't want to do anything that might be plagarism). I will ask for community advice if needed, but I want a fair crack at it first.

Either way, again, thanks for bringing these to my attention - I'm still relatively new on my coding journey so anything like this really is helpful.

1. In the description, the first sentence is way too long (break it), and there is no need to talk about undeterminate size since it is completely determined...
   Why not just say given a rectangular grid, find the largest such shape and return its size.

   And talking about formatting, use markdows wisely, for example :

   Features of random tests:

   The number of rows and columns in grid will always :

   • be inbetween 4 and 20 (inclusive)
   • be populated by positive integers between 1 and 5.

2. Why such a limit for the rectangle dimensions? Python is able to handle much bigger arrays.

3. In the submit tests, the number of them is way too low. With some luck and a falsy logic, users could pass.

4. The final -1 remark does not add anything to the description.

I think it's solved now.

I understand, I've edited the description to specify the features of the random tests - thanks for clarifying, makes sense and seems like good practice.

I use zeros in my solution. It isn't the best approach, but it's a good idea to specify input range in general to know data types to use in other languages. When input doesn't include the only falsy number, there's always a question of whether it's by design.

Specifying in the description if values will always be greater than 0 or not should be enough.

Currently, the numbers in the tests are always positive, however I can change them to generate 0s or specify the conditions in the random tests in the description - I personally don't see why 0s in the grid would present issues (as we just need to check that adjacent integers are equal), but it's very possible I'm just missing something - would you mind detailing what type of solution would make this an issue (or any other reasoning behind why this would be a good change) quickly? Thanks

Are the numbers always positive? I'm worried about zeros in the grid more than about negative indices.

Nice!