README Roadmap and Intended PR Schedule#10
Conversation
vp314
left a comment
vp314
left a comment
There was a problem hiding this comment.
Please think through what the file structure should look like. In the PR section, each PR should be its own subsection and there should be a table indicating what functionality/files are being implemented, their purpose, etc.
| src/ | ||
| RidgeRegression.jl | ||
|
|
||
| algorithms/ | ||
| bidiagonalization.jl | ||
| closed_form.jl | ||
| gradient_descent.jl | ||
| stochastic_gradient_descent.jl | ||
|
|
||
| datasets.jl | ||
| design.jl | ||
|
|
||
| test/ | ||
| runtests.jl | ||
|
|
||
| dataset_tests.jl | ||
| design_tests.jl | ||
| bidiagonalization_tests.jl | ||
| closed_form_tests.jl | ||
| gradient_descent_tests.jl | ||
| stochastic_gradient_descent_tests.jl | ||
|
|
||
| docs/ | ||
| src/ | ||
| index.md | ||
| design.md | ||
| api.md | ||
| ``` |
There was a problem hiding this comment.
Use vertical bars and dashes to ensure spacing is correct
|
|
||
| # Directory Structure | ||
|
|
||
| The source-code layout will be structured as such: |
| │ | ||
| ├── src | ||
| │ ├── RidgeRegression.jl | ||
| │ ├── units.jl |
| │ ├── dataset_tests.jl | ||
| │ ├── encoding_tests.jl | ||
| │ ├── load_csv_dataset_tests.jl | ||
| │ ├── closed_form_tests.jl | ||
| │ ├── gradient_descent_tests.jl | ||
| │ ├── stochastic_gradient_descent_tests.jl | ||
| │ ├── compute_givens_test.jl | ||
| │ ├── rotate_rows_test.jl | ||
| │ ├── rotate_cols_test.jl | ||
| │ ├── apply_Ht_to_b_test.jl | ||
| │ └── bidiagonalize_with_H_test.jl |
There was a problem hiding this comment.
This should be structured similarly to src/
So there should be a directory called src/
If you have multiple test files for a file in the src/ folder, then you can use a similar naming convention. For instance, if units.jl had two files "structs" and "onehotencode"
- units_structs.jl
- units_onehot_encode.jl
| └── docs | ||
| ├── make.jl | ||
| └── src | ||
| ├── design.md | ||
| └── index.md |
There was a problem hiding this comment.
Do some background research on documentation for software. Think about what makes the most sense for you.
Also think about the fact that you have an experiment that this software runs. So it should clearly indicate entry points to the code and exit points (e.g., tables, figures, datasets, etc.). So your documentation should also explain this as well.
For instance, "design.md" is not something you would find in standard software documentation but it is something you would find here.
Co-authored-by: Vivak Patel <vp314@users.noreply.github.com>
3 participants
Add project roadmap and anticipated pull request schedule to README
Description
This PR updates the README with a project roadmap which includes:
-Intended source code structure and organization
-Planned development sequence
-An expected PR schedule for future work
Motivation and Context
The goal of this PR is to make the project structure and development plan clear for contributors and reviewers.
Types of changes
Checklists:
Code and Comments
If this PR includes modifications to the code base, please select all that apply.
API Documentation
Manual Documentation
Testing
@code_lowered and
@code_typed)