Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate algorithms in maths/primelib.py #10703

Open
tianyizheng02 opened this issue Oct 19, 2023 · 5 comments
Open

Duplicate algorithms in maths/primelib.py #10703

tianyizheng02 opened this issue Oct 19, 2023 · 5 comments
Labels
enhancement This PR modified some existing files

Comments

@tianyizheng02
Copy link
Contributor

Feature description

maths/primelib.py contains multiple functions for commonly-used computations related to primes (sieve of Eratosthenes, least common multiple, prime factors, etc.), and most if not all of these are also implemented in other files. In an effort to remove duplicate algorithms, should we delete maths/primelib.py in favor of separate files for each algorithm, or should we delete the other files and consolidate their implementations into maths/primelib.py?

@tianyizheng02 tianyizheng02 added the enhancement This PR modified some existing files label Oct 19, 2023
@casanova1510

This comment was marked as off-topic.

@tianyizheng02
Copy link
Contributor Author

@casanova1510 Clearly you did not read the contributing guidelines, much less the content of this issue.

@olandodeflexy
Copy link

@tianyizheng02 this sounds like a microservices or monolithic kind of question. Of course using the single math/primelib.py will make the code base easier to maintain in terms of the number of files but not the code base itself. In my opinion working with modules is always the best. It gives you the room to work on an agile level and make significant improvements. With the project doing algorithmic calculations you wouldn't want to over complicate the calculations. An unassigned variable can cause a of problems in the single monolithic code base. in contrast having a modular single file for each algorithm will prevent this problem. In my candid opinion stick with the single files.

@piyush-poddar
Copy link
Contributor

@tianyizheng02 @olandodeflexy Shall we delete maths/primelib.py then?

@excellentpu
Copy link

@tianyizheng02 When deciding whether to delete maths/primelib.py and distribute the implementation of related algorithms to other files, several factors need to be weighed:

Modularity and readability: Placing the implementation of each algorithm in a separate file can improve code readability and modularity. Each function or class is in a separate file, which makes it easier for readers to find the definition of a specific function or class.
Code duplication: If there are similar algorithm implementations in multiple files, this may be a form of code duplication, which may violate the principle of "don't repeat yourself" (DRY). If these algorithms need to be modified later, making the same changes in multiple files may lead to errors.
File quantity and maintenance: If there are many such algorithms, a large number of files may be created. A large number of files may complicate the project structure and may increase the complexity of maintenance.
Performance and execution speed: If these algorithms are performance-critical, placing them in a single file may help improve execution speed.
If these algorithms are not particularly complex and can be easily found when needed, it may be appropriate to place them in a single file. However, if these algorithms are complex or if they need to be modified frequently, it may be better to place them in separate files. This can make the code easier to understand and maintain.

In general, there is no absolute answer to this question. Depending on the specific needs and context of the project, you may need to weigh these factors and make the best decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This PR modified some existing files
Projects
None yet
Development

No branches or pull requests

5 participants