Unify O(sqrt(N))is_prime functions under project_euler

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍

[ngiachou]

Describe your change:

I changed the implementation of is_prime functions inside project_euler in order to have a unified implementation. There are some cases where the solution uses the Eratosthenes' sieve method. In some cases there is no specific gain from using that method so I changed it to the O(sqrt(n)) algorithm, but in other cases the sieve method is used in the core structure of the solution, hence I did not touch those.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms have a URL in its comments that points to Wikipedia or other similar explanation.
• If this pull request resolves one or more open issues then the commit message contains Fixes: #{$ISSUE_NO}.

fixes#5434

[ngiachou]

I think it is better to remove the assertion in all together since it doesn't have actual value for the implementation of the primality test algorithm and maybe it is a bit of confusing even. Should I do that? @poyea

Edit: For example in project_euler/problem_003/sol1.py lines 41-43.

[poyea]

@elpaxoudis Yeah, I think they can be removed, and the negative / type check can be performed when processing input (if any). If we want to handle the negative / type check in the function, I think it makes sense to raise an exception / an assertion failure, instead of return False.

[poyea]

Thank you for your pull request!🤩

[ngiachou]

@poyea Is there any other changes I should make?

[poyea]

It's been a while and this looks good to me. 👍