It should generally be understood by site practitioners that the description should be universal (language agnostic) and as such when looking at data the type used is not critical, so long as the specs are clear for the user to comprehend and procede coding in the language of their choice.

Otherwise it becomes very messy in terms of maintaining the description as new languages are added.

The beta process exists to resolve issues before potential approval. While my solution might be ridiculous to you, input modification of mutable objects is an issue. Anyways, if you stick around long enough on codewars, that and not having random tests come up a lot in beta testing.

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

Please note that when you use a chat bot for generating content, the copyright might not be yours. Instead, I suggest you write the description yourself, and let a chat bot proof read it. This way, the copyright definately remains yours.

Yeah, you are right. Before writing this kata, I seached for duplicate but thinking that kata is easy, I only searched 7kyu and 8kyu. But the duplicate kata was in 6kyu. I generated title, problem statement using chatgpt. Even the title is also same.

kata retired

I agree. I overestimated the kata's difficulty by a lot. I have also approved your Python translation, brodiemark. Thanks for the translation, it will help the kata get more popular.

The average rating seems to be around 6kyu. Need to get more ratings to get it approved.

Could we please keep the language cleaner around here?

retired

Your solution is almost good, but has a bug, and becomes inaccurate at some point. See following:

Here is row 57 (yours vs expected), which is correct:

Yours:    1, 56, 1540, 27720, 367290, 3819816, 32468436, 231917400, 1420494075, 7575968400, 35607051480, 148902215280, 558383307300, 1889912732400, 5804731963800, 16253249498640, 41648951840265, 97997533741800, 212327989773900, 424655979547800, 785613562163430, 1346766106565880, 2142582442263900, 3167295784216200, 4355031703297275, 5574440580220512, 6646448384109072, 7384942649010080, 7648690600760440, 7384942649010080, [...]
Expected: 1, 56, 1540, 27720, 367290, 3819816, 32468436, 231917400, 1420494075, 7575968400, 35607051480, 148902215280, 558383307300, 1889912732400, 5804731963800, 16253249498640, 41648951840265, 97997533741800, 212327989773900, 424655979547800, 785613562163430, 1346766106565880, 2142582442263900, 3167295784216200, 4355031703297275, 5574440580220512, 6646448384109072, 7384942649010080, 7648690600760440, 7384942649010080, [...]

Here is row 58 (yours vs expected), which starts getting inaccurate:

Yours:    1, 57, 1596, 29260, 395010, 4187106, 36288252, 264385836, 1652411475, 8996462475, 43183019880, 184509266760, 707285522580, 2448296039700, 7694644696200, 22057981462440, 57902201338905, 139646485582065, 310325523515700, 636983969321700, 1210269541711230, 2132379668729310, 3489348548829780, 5309878226480100, 7522327487513475, 9929472283517788, 12220888964329584, 14031391033119152, 15033633249770520, 15033633249770520, 14031391033119152, [...]
Expected: 1, 57, 1596, 29260, 395010, 4187106, 36288252, 264385836, 1652411475, 8996462475, 43183019880, 184509266760, 707285522580, 2448296039700, 7694644696200, 22057981462440, 57902201338905, 139646485582065, 310325523515700, 636983969321700, 1210269541711230, 2132379668729310, 3489348548829780, 5309878226480100, 7522327487513475, 9929472283517787, 12220888964329584, 14031391033119152, 15033633249770520, 15033633249770520, 14031391033119152, [...]

See how your solutions gets 9929472283517788 vs 9929472283517787 incorrectly at row 58. Similarly, all rows beyond 58 contain more and more incorrect numbers. You need to fix a bug in your solution (a very small one!)