We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
Hi guys! I'm quite new here so feel free to point me somewhere if this is not the right place for this post
I claim that the test cases are not checking for one fringe case, they lets solutions through with an error. (Found it when reviewing my own code for an interview that had this error :P )
The case is when we have a number that is a square of a prime (ex 289 = 17*17), this should be NOT PRIME, but my algorithm says on manual input PRIME and still passes all test-cases given for "submit code"
In code this issue can be caused when we mess up loop boundries like:
for i in range(3,sqrt(n)):
...
which in Python does not include the actual number sqrt(n), but stops right before. This is ok for all cases except squares of primes, but it will let erroneous code through.
So I would sugest extending one of the test-cases with checking for a: "squared prime number == NOT PRIME" to catch this in the future
Cookie support is required to access HackerRank
Seems like cookies are disabled on this browser, please enable them to open this website
Time Complexity: Primality
You are viewing a single comment's thread. Return to all comments →
Hi guys! I'm quite new here so feel free to point me somewhere if this is not the right place for this post
I claim that the test cases are not checking for one fringe case, they lets solutions through with an error. (Found it when reviewing my own code for an interview that had this error :P )
The case is when we have a number that is a square of a prime (ex 289 = 17*17), this should be NOT PRIME, but my algorithm says on manual input PRIME and still passes all test-cases given for "submit code"
In code this issue can be caused when we mess up loop boundries like: for i in range(3,sqrt(n)): ...
which in Python does not include the actual number sqrt(n), but stops right before. This is ok for all cases except squares of primes, but it will let erroneous code through.
So I would sugest extending one of the test-cases with checking for a: "squared prime number == NOT PRIME" to catch this in the future