Prime_factors is linear in the values of the elements, times the log(n_elements) insertion time into the hashmap times the number of elements - this risks scaling as n^3 - which means it will be slow, especially on arrays of many large numbers

LGTM

Kotlin translation up. Please help review!

Approved.

Thank you Zeno; we now have 13 languages available!

Should there be any problems specific to Kotlin: if you comment on this post, the author of the translation will see it.

Thanks for the review! I've edited per your comments.

It was called Randomrests with the original Java version I had during the translation, so not sure if that's also an issue with other language versions

Random Tests is called Random Rests.

Please make the language-specific block for the function definition explicit. You're now lifting along on Go, I think. You can either copy the block or reuse an existing block by separating the languages with a comma ( no spaces, I think ).

I don't speak Kotlin, so I have to take your word for a lot of things. I'm quite willing to do that, but it also means I'm not going to change anything myself. I'm not lazy; I just don't dare. :P

Kotlin translation up! Please help review :)

What's the problem with the package statement? I don't think it can cause any problem.

You can use

object solution {
  // things originally in your package
}

though.

Could you please rate this Kata and give your satisfaction?

Otherwise this Kata will never get approved to be a non-beta Kata (which means non of you guys will actually earn honor by doing this).

Anyway we can remove the package solution? Tripped by this once

They can't be of different sizes, otherwise they're unequal by any definition of array equality.

The 'Note for C' part just means that because you can't get array length in C easily, it's supplied as a function argument to save you the hassle.