dam it.. I was thinking I'm one test away from to compleating this kata..

Phew...! Eventually!

It took me ages to achieve the performance required to solve this kata. My initial algorithm took 11 seconds for a 67 rows by 59 columns reference shape. In the final solution I got this down to 0.038 seconds.

It's a great kata to develop techniques to identify where your algorithm actually spends time.

Nice one! Thank you!

Not quite there yet. I guess you are able to see an earlier version I submitted. I still haven't passed all the tests. I reckon I still have to improve the performance by a factor 3 to 4.

This kata got me into a russian doll of problems. You implement an algorithm to speed up one aspect of the solution, only to realise that this causes problems elsewhere. Once you fixed those, you need specialised code in another function. And so one and so forth ...

I have an idea now. Let me see if that works ...

I'd say no, because if you need the optimizations here, that means you're not using the best approach (otherwise you made "performances-wise mistakes" in the way you coded it, I guess). Moreover, the number of random tests would be adjusted to match the original translation, if it were to be a C translation, I guess.

cheers

edit: wow... I just saw your solution: sounds like you did it the hard way. ;) Congrats, because it's a nightmare to complete it that way! (I know it: I did the same... XD )

Out of curiosity: would the solution code be much simpler when you try to solve this in C or C#? Has anyone tried? I'm going through hoops to achieve the performance required to solve this kata. Makes me wonder, if you encounter a challenge like this in a real life project, would this be an example for choosing a different programming language?

That's interesting. I do use dicts but I consciously avoided dependency on the order of keys. I must have done that somewhere unintentionally. I'll have a look.

ok, then I have my idea about the cause: I bet you're using a dict on which you're iterating somewhere, and that the order of the iteration is important to your algo: for 3.6+, the dict are retaining the insertion order of the keys, when iterating over them or their properties (values/items...). That's officially documented for 3.7+ only but the feature is already present in 3.6. In older version, the order is not guaranteed during iterations.

right?

Yes, just tested it. It works well with 3.6.0.

sound so, yes... :/ Unfortunately, not knowing your code and, more over, not knowing the differences between 3.7.3 and lower 3.x, I have no clue about the cause. Did you try in 3.6 already?

I just noticed: when I switch codewars Python version from 3.4.3 to 3.6.0 my code passes the "Yin-Yang" test. That's interesting. I need to figure out what causes this.

I have this odd behaviour that my code fails test case "Yin-Yang" on the codewars platform. It produces only two of the required three pieces. However, when I run it on my local machine (Windows 10, Python 3.7.3) it produces the expected three pieces. Is this an issue with the Python version? Any advise?

Great kata!

He solved the hackcodewars kata

oops!