Seems like an unintentional randomness snuck into this one.

My first several attempts failed by timing out. I made some changes that helped, but it seems like the most important thing was that my randomly selected tests had smaller prime factors the last couple of times. Since I'm doing a linear search through the possible factors, it runs a lot faster if the biggest factor is not so huge.

Anyone else notice the same thing? Maybe my code is just slow...

Anyone else notice the same thing? Maybe my code is just slow...

Yes, I have the same problem with my program. I usually have to submit it 3 or 4 times before it passes.

Anyone else notice the same thing? Maybe my code is just slow...

Yes, I have the same problem with my program. I usually have to submit it 3 or 4 times before it passes.

I've noticed the same thing...maybe this problem should have an additional constraint that says that the largest prime in the factorization will be less than n (where n is maybe 100,000?) Or maybe there should be an intentionally huge prime in the problem, to consistently trip us up if we don't stop when we should.

In looking for prime factors of n, it's only necessary to search up to sqrt(n). However, since code size is the name of the game, my 'best' solution continues to blindly search up to n.

Same thing here. My code has pathological performance on certain numbers. Luckily they don't seem to be all that common!

Of course, I'm second-worst in this challenge's Python entries, so don't pay too much attention to how I did it!