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

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.

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.

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

Thank you, updated the description to reflect these suggestions. Good catch on the last row too, somehow missed that when writing up the description - should be more language agnostic now

Thanks for bringing these up, I've made some edits - should hopefully be better now, but let me know if it's still got these (or similar) issues.

While this is in beta, just a few notes:

This is my first time publishing a Kata, and I'm relatively new to coding so there's doubtless some things I'm doing wrong - any contributions are appreciated, and any explanations on them even more so. I couldn't find a similar enough Kata on a cursory look through, but it's very possible they exist - if anyone knows of one, let me know here. Similarly, any translations into other languages or suggestions on how to change the description for them are appreciated.

Heya, just quickly checking in because this clearly shouldn't be able to happen - how do you prevent this type of issue? Thanks in advance