Fastest primality test c++ [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
-4
down vote

favorite












I've seen 2 versions of an algorithm for determining the primality of a number, and I think the first one is better, as you skip all the even numbers(I know they're almost the same thing, just wondering if the first one is any better). Which version is generally better?



bool is_prime1(int x)
x % 2 == 0)
return false;

int p = sqrt(x);
for (int i = 3; i <= p; i += 2)
if (x % i == 0)
return false;

return true;




bool is_prime2(int x)

if (x == 1)
return false;

int p = sqrt(x);
for (int i = 2; i <= p; ++i)
if (x % i == 0)
return false;

return true;







share|improve this question













closed as off-topic by πάντα ῥεῖ, Jamal♦ Jan 7 at 20:19


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.












  • At least in my experience, yes, the first is (somewhat) better. Did you just want an answer to that question, or do you want a review of the code in general? (That's what we normally do here).
    – Jerry Coffin
    Jan 7 at 19:44










  • @JerryCoffin I’d also like to see how can I improve my coding style
    – Semetg
    Jan 7 at 19:47










  • Did you just find this code or did you actually write it?
    – Jamal♦
    Jan 7 at 20:20
















up vote
-4
down vote

favorite












I've seen 2 versions of an algorithm for determining the primality of a number, and I think the first one is better, as you skip all the even numbers(I know they're almost the same thing, just wondering if the first one is any better). Which version is generally better?



bool is_prime1(int x)
x % 2 == 0)
return false;

int p = sqrt(x);
for (int i = 3; i <= p; i += 2)
if (x % i == 0)
return false;

return true;




bool is_prime2(int x)

if (x == 1)
return false;

int p = sqrt(x);
for (int i = 2; i <= p; ++i)
if (x % i == 0)
return false;

return true;







share|improve this question













closed as off-topic by πάντα ῥεῖ, Jamal♦ Jan 7 at 20:19


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.












  • At least in my experience, yes, the first is (somewhat) better. Did you just want an answer to that question, or do you want a review of the code in general? (That's what we normally do here).
    – Jerry Coffin
    Jan 7 at 19:44










  • @JerryCoffin I’d also like to see how can I improve my coding style
    – Semetg
    Jan 7 at 19:47










  • Did you just find this code or did you actually write it?
    – Jamal♦
    Jan 7 at 20:20












up vote
-4
down vote

favorite









up vote
-4
down vote

favorite











I've seen 2 versions of an algorithm for determining the primality of a number, and I think the first one is better, as you skip all the even numbers(I know they're almost the same thing, just wondering if the first one is any better). Which version is generally better?



bool is_prime1(int x)
x % 2 == 0)
return false;

int p = sqrt(x);
for (int i = 3; i <= p; i += 2)
if (x % i == 0)
return false;

return true;




bool is_prime2(int x)

if (x == 1)
return false;

int p = sqrt(x);
for (int i = 2; i <= p; ++i)
if (x % i == 0)
return false;

return true;







share|improve this question













I've seen 2 versions of an algorithm for determining the primality of a number, and I think the first one is better, as you skip all the even numbers(I know they're almost the same thing, just wondering if the first one is any better). Which version is generally better?



bool is_prime1(int x)
x % 2 == 0)
return false;

int p = sqrt(x);
for (int i = 3; i <= p; i += 2)
if (x % i == 0)
return false;

return true;




bool is_prime2(int x)

if (x == 1)
return false;

int p = sqrt(x);
for (int i = 2; i <= p; ++i)
if (x % i == 0)
return false;

return true;









share|improve this question












share|improve this question




share|improve this question








edited Jan 7 at 22:05









13ros27

23114




23114









asked Jan 7 at 18:38









Semetg

767




767




closed as off-topic by πάντα ῥεῖ, Jamal♦ Jan 7 at 20:19


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by πάντα ῥεῖ, Jamal♦ Jan 7 at 20:19


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." – Jamal
If this question can be reworded to fit the rules in the help center, please edit the question.











  • At least in my experience, yes, the first is (somewhat) better. Did you just want an answer to that question, or do you want a review of the code in general? (That's what we normally do here).
    – Jerry Coffin
    Jan 7 at 19:44










  • @JerryCoffin I’d also like to see how can I improve my coding style
    – Semetg
    Jan 7 at 19:47










  • Did you just find this code or did you actually write it?
    – Jamal♦
    Jan 7 at 20:20
















  • At least in my experience, yes, the first is (somewhat) better. Did you just want an answer to that question, or do you want a review of the code in general? (That's what we normally do here).
    – Jerry Coffin
    Jan 7 at 19:44










  • @JerryCoffin I’d also like to see how can I improve my coding style
    – Semetg
    Jan 7 at 19:47










  • Did you just find this code or did you actually write it?
    – Jamal♦
    Jan 7 at 20:20















At least in my experience, yes, the first is (somewhat) better. Did you just want an answer to that question, or do you want a review of the code in general? (That's what we normally do here).
– Jerry Coffin
Jan 7 at 19:44




At least in my experience, yes, the first is (somewhat) better. Did you just want an answer to that question, or do you want a review of the code in general? (That's what we normally do here).
– Jerry Coffin
Jan 7 at 19:44












@JerryCoffin I’d also like to see how can I improve my coding style
– Semetg
Jan 7 at 19:47




@JerryCoffin I’d also like to see how can I improve my coding style
– Semetg
Jan 7 at 19:47












Did you just find this code or did you actually write it?
– Jamal♦
Jan 7 at 20:20




Did you just find this code or did you actually write it?
– Jamal♦
Jan 7 at 20:20










1 Answer
1






active

oldest

votes

















up vote
1
down vote



accepted










At least when I've timed things, code like the first was generally faster than the second. The obvious way to check this is to simply time both for various input values--faster is an objective measurement, so there's not a lot of question about the right answer.



There is still room for further improvement in many cases though. First of all, the call to sqrt looks fairly innocent, but is often quite slow. In any cases, it's faster to do something like this instead:



for (int i = 3; i * i <= x; i += 2)


Again, the only way to be sure is to time it though.



Depending on your situation, it can also be worth using a sieve of Eratosthenes to find candidate primes, and only do trial division by those candidates. This won't typically help (much, anyway) for smaller numbers, but above some threshold it tends to become more useful.



The biggest problem I see other than that is just names. For example, I'd prefer something like candidate_divisor instead of i and candidate_prime instead of x. For a function this tiny it's unlikely to make a huge difference though.






share|improve this answer




























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote



    accepted










    At least when I've timed things, code like the first was generally faster than the second. The obvious way to check this is to simply time both for various input values--faster is an objective measurement, so there's not a lot of question about the right answer.



    There is still room for further improvement in many cases though. First of all, the call to sqrt looks fairly innocent, but is often quite slow. In any cases, it's faster to do something like this instead:



    for (int i = 3; i * i <= x; i += 2)


    Again, the only way to be sure is to time it though.



    Depending on your situation, it can also be worth using a sieve of Eratosthenes to find candidate primes, and only do trial division by those candidates. This won't typically help (much, anyway) for smaller numbers, but above some threshold it tends to become more useful.



    The biggest problem I see other than that is just names. For example, I'd prefer something like candidate_divisor instead of i and candidate_prime instead of x. For a function this tiny it's unlikely to make a huge difference though.






    share|improve this answer

























      up vote
      1
      down vote



      accepted










      At least when I've timed things, code like the first was generally faster than the second. The obvious way to check this is to simply time both for various input values--faster is an objective measurement, so there's not a lot of question about the right answer.



      There is still room for further improvement in many cases though. First of all, the call to sqrt looks fairly innocent, but is often quite slow. In any cases, it's faster to do something like this instead:



      for (int i = 3; i * i <= x; i += 2)


      Again, the only way to be sure is to time it though.



      Depending on your situation, it can also be worth using a sieve of Eratosthenes to find candidate primes, and only do trial division by those candidates. This won't typically help (much, anyway) for smaller numbers, but above some threshold it tends to become more useful.



      The biggest problem I see other than that is just names. For example, I'd prefer something like candidate_divisor instead of i and candidate_prime instead of x. For a function this tiny it's unlikely to make a huge difference though.






      share|improve this answer























        up vote
        1
        down vote



        accepted







        up vote
        1
        down vote



        accepted






        At least when I've timed things, code like the first was generally faster than the second. The obvious way to check this is to simply time both for various input values--faster is an objective measurement, so there's not a lot of question about the right answer.



        There is still room for further improvement in many cases though. First of all, the call to sqrt looks fairly innocent, but is often quite slow. In any cases, it's faster to do something like this instead:



        for (int i = 3; i * i <= x; i += 2)


        Again, the only way to be sure is to time it though.



        Depending on your situation, it can also be worth using a sieve of Eratosthenes to find candidate primes, and only do trial division by those candidates. This won't typically help (much, anyway) for smaller numbers, but above some threshold it tends to become more useful.



        The biggest problem I see other than that is just names. For example, I'd prefer something like candidate_divisor instead of i and candidate_prime instead of x. For a function this tiny it's unlikely to make a huge difference though.






        share|improve this answer













        At least when I've timed things, code like the first was generally faster than the second. The obvious way to check this is to simply time both for various input values--faster is an objective measurement, so there's not a lot of question about the right answer.



        There is still room for further improvement in many cases though. First of all, the call to sqrt looks fairly innocent, but is often quite slow. In any cases, it's faster to do something like this instead:



        for (int i = 3; i * i <= x; i += 2)


        Again, the only way to be sure is to time it though.



        Depending on your situation, it can also be worth using a sieve of Eratosthenes to find candidate primes, and only do trial division by those candidates. This won't typically help (much, anyway) for smaller numbers, but above some threshold it tends to become more useful.



        The biggest problem I see other than that is just names. For example, I'd prefer something like candidate_divisor instead of i and candidate_prime instead of x. For a function this tiny it's unlikely to make a huge difference though.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered Jan 7 at 19:58









        Jerry Coffin

        27.4k360123




        27.4k360123












            Popular posts from this blog

            Greedy Best First Search implementation in Rust

            Function to Return a JSON Like Objects Using VBA Collections and Arrays

            C++11 CLH Lock Implementation