Python's standard library functions are implemented in C, so not only is this solution cleaner, it's also significantly faster, than your reinvent-the-wheel solution.
first time I solved something so easily and it was the first solution (I'm always trying to get the same solution as the first, even if I know how to write it less elegantly)
I'm not too sure, but I think these builtins are internally written in C, making them automatically blazing fast. Calling the solution "horribly inefficient" is really dramatic. On the grand scheme of things, this is still an O(n) solution. It is also incredibly readable. I have run some cursory benchmarks and the "inefficient" method gobsmacks yours for all list lengths I've tried (we're talking around more than 3x faster than yours). Take this with a grain of salt since they're informal tests, but it should hopefully make you reconsider making hasty performance comments in the future. I'll attach it spoilered below.
ok, that's your opinion, facts tell a different story on performance...
Python's standard library functions are implemented in C, so not only is this solution cleaner, it's also significantly faster, than your reinvent-the-wheel solution.
This comment is hidden because it contains spoiler information about the solution
we think same xd..... simplicity is best
This solution have a problem with n1 = n^x and n2 = m^y
these types of questions convinced me to start learning number theory, mind if you tell me specifically whats this about?
me too)))
first time I solved something so easily and it was the first solution (I'm always trying to get the same solution as the first, even if I know how to write it less elegantly)
Wow, I used number theory in my solution, but it wasn't anywhere near this compact
No, it is fast.
I'm not too sure, but I think these builtins are internally written in C, making them automatically blazing fast. Calling the solution "horribly inefficient" is really dramatic. On the grand scheme of things, this is still an O(n) solution. It is also incredibly readable. I have run some cursory benchmarks and the "inefficient" method gobsmacks yours for all list lengths I've tried (we're talking around more than 3x faster than yours). Take this with a grain of salt since they're informal tests, but it should hopefully make you reconsider making hasty performance comments in the future. I'll attach it spoilered below.
can't think of any other solution
#11bfr_42x
your solution is very elegant . thanks for the intel .
python is a black art .
No. If you parse the array twice it's still O(N) (O(2N) == O(N)). O(N^2) would be the case of a nested loop.
Your reply is non-sensical...I'm not sure where language comes into play here.
This solution runs in O(N^2) because it requires iterating through the array twice before returning.
With a two pointer solution, you traverse the array once, in O(N), which is more efficient.
Loading more items...