I think the basic test cases should include at least one where the expected return value is an empty vector. I got a little confused at one point and ended up treating this as a "filter" problem instead of a "takeWhile" (my fault!), but with a better local test suite, that wouldn't have happened, I think.

This is still the case today.

I just learned something! I didn't know strings were mutable in C++ (coming from Java).

Thanks :) Although now that I'm looking at it again, it could use a tiny bit of refactoring.

I've solved harder 4th and 5th kyu katas. This is the first one that made me cringe.

Ah, you're right. My apologies; I missed that when reading the description.

I think it could use a few more test cases. For example, I had an issue submitting because your tests expected the prime factors to be in ascending order, but I had used an unordered implementation. On that note, the description should state explicitly that the primes must be ordered.

You might also consider using longs instead of ints for a harder challenge. The algorithm to find prime factors would then need to be more efficient.

Finally, perhaps state in the description that it would be helpful to solve the PrimeFactorizer kata first, as that solution can be modified and reused in this kata. Or vice versa.

Can anyone recommend good materials (either books or online resources) for algorithms relating to number theory (primes/factorials/etc)? I'd appreciate any pointers :)

Actually, I think the description is fine. The only other thing I can think might be useful would be an example or two.

This kata is way too simple to qualify as 3rd kyu. Also, I really dislike the use of publicly-accessible mutable fields in this case. They really should be accessed via getters, and there's no reason at all for there to be setters. Finally, from a problem-statement standpoint, it would probably be simpler to just state what the API is. It wasn't clear, at first, that this problem required the aforementioned mutable public fields, rather than getters (it should require getters).

Best solution by far. No imports, one line, beautiful.

Could use lengthier description and possibly more test cases. E.g., could test very large arrays to test for efficient algorithm.

I completely agree. I don't think "1 2 3"should return 3. It should return 0, as a default.

Testing keeps timing out at 10000ms. I've benchmarked it and most runs take 0.00s, so there's no way I'm pushing 10s.

Here's a link to an image on DropBox showing the cumulative time spent by all the tests: https://www.dropbox.com/s/jyvwb0m4z0cxtw5/perfect_power_timing.png?dl=0

I simply return null and all the tests pass.

Link to DropBox showing screenshot illustrating issue: https://www.dropbox.com/s/v386ic55nud5mga/perfect_power_test_bug.jpg?dl=0