WIP: Dev branch documentation #65
Conversation
…iles like still images as alternatives to gifs and one python script to test installation
…tures, model architecture
|
|
||
| ## Contributing | ||
|
|
||
| Place for optional information about contributors or direction for how to contribute. For the latter --> the cadCAD [contributing](https://github.com/CADLabs/cadCAD/blob/master/CONTRIBUTING.md) directions are useful. |
There was a problem hiding this comment.
I agree with all these placeholders, let's fill in some MVP versions of each of these. For acknowledgements, let's follow the Ethereum Economic Model as a blueprint about how to automate this.
|
|
||
| ## Table of Contents | ||
|
|
||
| - [Acknowledgments](#acknowledgments) |
There was a problem hiding this comment.
Let's remove these table of contents on all pages. The table of contents is already automated and shown on the right hand side in MkDocs.
| * Only works for single subsets (no parameter sweeps) | ||
|
|
||
|
|
||
| ## Model implementation |
There was a problem hiding this comment.
I'm not sure this is an accurate title for what is included below - Model is one of the classes, the content below is about model, simulation, etc.
|
|
||
| --- | ||
|
|
||
| ## Model classes and specifications |
There was a problem hiding this comment.
This section includes one subsection - "Iterating over a Model". I don't think "Model classes and specifications" is an accurate title for the section.
| @@ -0,0 +1,97 @@ | |||
| ## cadCAD Compatibility | |||
There was a problem hiding this comment.
Given the section "cadCAD Compatibility" is a page under "Reference", is it possibly to have this structure in the directory structure too for all pages? This would make it easier to navigate and review structure I think.
| - Examples: examples.md | ||
| - Examples (accessible): examples_accessible.md | ||
| - Features: | ||
| - Features: features.md |
There was a problem hiding this comment.
Is it possible to not repeat the title as in "Features/Features", "Examples/Examples", "Reference/Reference"? It can be confusing to navigate.
|
|
||
| ## Development | ||
|
|
||
| Jump to [Development](development.md) section for information about: |
There was a problem hiding this comment.
These summary sections referencing other pages are unnecessary I think and will become difficult to maintain.
| # print(df.head(10)) | ||
| # To analyse the last 10 rows of the raw results | ||
| # print(df.tail(10)) | ||
| print(f"The final sizes of the populations are, prey: {df['prey_population'][2001]} and predator: {df['predator_population'][2001]}.") |
There was a problem hiding this comment.
Let's remove hardcoded index - if the index were to change, this would break. Better to select the last row I think.
| @@ -15,6 +15,7 @@ cadCAD = { version = "^0.4.27", optional = true } | |||
| ray = { version = "^1.1.0", optional = true } | |||
| boto3 = { version = "^1.16.43", optional = true } | |||
| numpy = "^1.24.1" | |||
| ipywidgets = "7.7.2" | |||
There was a problem hiding this comment.
ipywidgets is not a core dependency I think, it should be under dev-dependencies. If we include it here, then anyone who installs radCAD will also be installing ipywidgets.
| @@ -1,3 +1,6 @@ | |||
| """Backend here! | |||
There was a problem hiding this comment.
Let's make these titles consistent - they will appear in the automated documentation. Suggest seeing what the best practise is from Google. Backend here! should be a summary, or left blank if we only want a summary for each of the specific backends below.
There was a problem hiding this comment.
Let's describe here what a Backend is.
| @@ -1,3 +1,7 @@ | |||
| """Backend that allows multiprocessing | |||
| No examples now. | |||
There was a problem hiding this comment.
Instead of No examples now., let's use TODO or leave blank.
I've created a pull request for the mkdocs documentation.
The static pages are on my fork, and are available at: https://abzaremba.github.io/radCAD/
I would appreciate comments :)