Our challenges platform hosts competitions where the winning solutions are subsequently open-sourced and integrated into our library as components.
[x] Suggestion 1: I recommend incorporating markdown files that detail each component within the include/ directory's respective subdirectories. While our blog provides comprehensive summaries of these challenges, the content tends to be heavily focused on the competitions themselves. A more effective approach would be to extract and repurpose the functionality descriptions from these blog posts, using them to clearly articulate each component's purpose and capabilities within its markdown description.
[ ] Suggestion 2: It's also valuable to communicate the advantages of these components. Extract insights and highlights from our blog posts to articulate why these components stand out. This will not only inform users about the functionalities of the components but also convey their value and the problem-solving capabilities they bring to the table.
[ ] Suggestion 3: In the bin directory, we currently have binaries to build the particular component. I suggest adding some minor markdowns the as well.
By implementing these suggestions, we can enhance the repository's navigability and provide users with a clearer understanding of each component's functionality and benefits, directly linking the practical applications of our competition outcomes to real-world problem-solving scenarios.
Expected structure of the cpp dir after implementing all three suggestions:
├── CMakeLists.txt # Top-level CMake configuration
├── src/
├── include/
│ ├── matrix_mult/
│ │ ├── ckks.hpp
│ │ └── README.md # Description of matrix_mult component
│ ├── sigmoid/
│ │ ├── ckks.hpp
│ │ └── README.md # Description of sigmoid component
│ └── signum/
│ │ ├── ckks.hpp
│ │ └── README.md # Description of signum component
├── bin/
│ ├── matrix_mult/
│ │ ├── CMakeLists.txt
│ │ ├── main.cpp
│ │ └── README.md # Description and usage of matrix_mult standalone component bin
│ ├── sigmoid/
│ │ ├── CMakeLists.txt
│ │ ├── main.cpp
│ │ └── README.md # Description and usage of sigmoid standalone component bin
│ └── signum/
│ │ ├── CMakeLists.txt
│ │ ├── main.cpp
│ │ └── README.md # Description and usage of signum standalone component bin
Our challenges platform hosts competitions where the winning solutions are subsequently open-sourced and integrated into our library as components.
[x] Suggestion 1: I recommend incorporating markdown files that detail each component within the include/ directory's respective subdirectories. While our blog provides comprehensive summaries of these challenges, the content tends to be heavily focused on the competitions themselves. A more effective approach would be to extract and repurpose the functionality descriptions from these blog posts, using them to clearly articulate each component's purpose and capabilities within its markdown description.
[ ] Suggestion 2: It's also valuable to communicate the advantages of these components. Extract insights and highlights from our blog posts to articulate why these components stand out. This will not only inform users about the functionalities of the components but also convey their value and the problem-solving capabilities they bring to the table.
[ ] Suggestion 3: In the bin directory, we currently have binaries to build the particular component. I suggest adding some minor markdowns the as well.
By implementing these suggestions, we can enhance the repository's navigability and provide users with a clearer understanding of each component's functionality and benefits, directly linking the practical applications of our competition outcomes to real-world problem-solving scenarios.
Expected structure of the cpp dir after implementing all three suggestions: