removed some misspellings, moved to apa

Author: codeallthethingz

.vale/styles/Docs/TitleCaseHeadings.yml

@@ -1,28 +1,7 @@
 extends: capitalization
-message: "%s should follow AMA title case."
+message: "%s should follow APA title case. (https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case)"
 level: error
 scope: heading
 match: $title
-style: AMA
-vocab: false
-exceptions:
-  - \ba\b
-  - \ban\b
-  - \band\b
-  - \bas\b
-  - \bat\b
-  - \bfor\b
-  - \bbut\b
-  - \bby\b
-  - \bif\b
-  - \bin\b
-  - \bdo\b
-  - \bwe\b
-  - \bof\b
-  - \bon\b
-  - \bor\b
-  - \bto\b
-  - \bup\b
-  - \bloader\b
-  - STM
-  - LTM
+style: APA
+vocab: false

.vale/styles/config/vocabularies/TBP/accept.txt

@@ -36,9 +36,7 @@ worldimages
 neocortical
 Initializer
 resample
-retreive
 actuations
-displacemnts
 Calli
 Omniglot
 iter
@@ -88,7 +86,6 @@ programatically
 timeseries
 pretrain
 misclassification
-succint
 _all_
 args
 eval
@@ -102,7 +99,6 @@ succesive
 interpretability
 Walkthrough
 presynaptic
-\befference\b
 subcortically
 Pytorch
 Guillery
@@ -136,11 +132,7 @@ Klukas
 Purdy
 xyz
 readme
-commande
-availabe
-triaged
 substep
-severities
 CLA
 unmerged
 github
@@ -153,9 +145,6 @@ rdme
 cli
 Exapmle
 semver
-serverity
-truely
-managable
 attriubtes
 callouts
 discretized
@@ -164,17 +153,13 @@ discretization
 profiler
 overconstrained
 loopdown
-acutation
 perceptrons
 bool
 gaussian
-aquired
-sequencce
 Cui
 learnable
 Eitan
 Azoff
-accross
 Sync'ing
 subdocuments
 sync'd
@@ -183,4 +168,7 @@ sync'd
 \bLeadholm\b
 \bKalman\b
 biofilm
-\bTolman's\b
+\bTolman's\b
+\befference\b
+\bEfference\b
+\bTriaged\b

docs/contributing/contributing.md

@@ -7,7 +7,7 @@ Welcome, and thank you for your interest in contributing to Monty!
 We appreciate all of your contributions. Below, you will find a list of ways to get involved and help create AI based on principles of the neocortex.
 
 
-# Contribute to Our Code
+# Contribute To Our Code
 
 There are many ways in which you can contribute to the code. For some suggestions, see the [Contributing Code Guide](ways-to-contribute-to-code.md).
 

docs/contributing/guides-for-maintainers/triage.md

@@ -23,7 +23,7 @@ The desired cadence for Issue Triage is at least once per business day.
 
 A **Maintainer** will check the Issue for validity.
 
-Do not assign priorities or severities to Issues (see: [RFC 2 PR and Issue Review](https://github.com/thousandbrainsproject/tbp.monty/blob/main/rfcs/0002_pr_and_issue_review.md#issue)).
+Do not assign priority or severity to Issues (see: [RFC 2 PR and Issue Review](https://github.com/thousandbrainsproject/tbp.monty/blob/main/rfcs/0002_pr_and_issue_review.md#issue)).
 
 Do not assign **Maintainers** to Issues. Issues remain unassigned so that anyone can work on them (see: [RFC 2 PR and Issue Review](https://github.com/thousandbrainsproject/tbp.monty/blob/main/rfcs/0002_pr_and_issue_review.md#feature-requests-1)).
 
@@ -81,7 +81,7 @@ First, check if the Pull Request CLA check is passing. If the check is not passi
 
 A **Maintainer** will check the Pull Request for validity.
 
-There are no priorities or severities applied to Pull Requests.
+There is no priority or severity applied to Pull Requests.
 
 A valid Pull Request is on-topic, well-formatted, contains expected information, does not depend on an unmerged Pull Request, and does not violate the code of conduct.
 

docs/contributing/style-guide.md

@@ -113,11 +113,11 @@ In general we try and stick to native markdown syntax, if you find yourself need
 
 In a document your first level of headings should be the `#` , then `##` and so on.   This is slightly confusing as usually `#` is reserved for the title, but on readme.com the `h1` tag is used for the actual title of the document.
 
-Use headings to split up long text block into managable chunks.
+Use headings to split up long text blocks into manageable chunks.
 
 Headings can be referenced in other documents using a hash link `[Headings](doc:style-guide#headings)`. For example [Style Guide - Headings](style-guide.md#headings)
 
-All headings should use capitalization following APA convention. For detailed guidelines see the [APA heading style guide](https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case).
+All headings should use capitalization following APA convention. For detailed guidelines see the [APA heading style guide](https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case) and this can be tested with the [Vale](https://vale.sh/) tool and running `vale .` in the root of the repo.
 
 ## Footnotes
 

docs/contributing/ways-to-contribute-to-code.md

@@ -16,6 +16,6 @@ There are many ways in which you can contribute to the code. The list below is n
 - **Add to our Benchmarks**: If you have ideas on how to test more capabilities of the system we appreciate if you add to our [benchmark experiments](../overview/benchmark-experiments.md). This could be evaluating different aspects in our current environments or adding completely new environments. Please note that in order to allow us to frequently run all the benchmark experiments, we only add one experiment for each specific capability we test and try to keep the run times reasonable.
 - **Work on an open Issue**: If you came to our project and want to contribute code but are unsure of what, the [open Issues](https://github.com/thousandbrainsproject/tbp.monty/issues) are a good place to start.  See our guide on [how to identify an issue to work on](ways-to-contribute-to-code/identify-an-issue-to-work-on.md) for more information.
 
-# How to Contribute Code
+# How To Contribute Code
 
 Monty integrates code changes using Github Pull Requests. To start contributing code to Monty, please consult the [Contributing Pull Requests](pull-requests.md) guide.

docs/contributing/why-contribute.md

@@ -12,7 +12,7 @@ We are excited about all contributors and there may be a wide range of motivatio
 - You want to solve a task that requires quick, continuous learning and adaptation.
 - You want to better understand the brain and principles underlying our intelligence.
 - You want to work on the future of AI.
-- You want to be part of a truely unique and special project.
+- You want to be part of a truly unique and special project.
 
 Here is a list of concrete output you may get out of working on this project.
 

docs/future-work/project-roadmap.md

@@ -19,7 +19,7 @@ Tasks are categorized in two ways:
 
 Tasks that are done have a check mark next to them and are shaded in green. When a task gets checked off, it will add progress to the corresponding capabilities on the right.
 
-# What the TBP Team is Working on
+# What the TBP Team is Working On
 
 Some of the tasks are under active development by our team or scheduled to be tackled by us soon. Those are shaded in color. Below the main table, you can find a **list of our past and current milestones** with more detailed descriptions, timeline, and who is working on it. The colors of the milestones correspond to the colors in the main table.
 

docs/how-monty-works/connecting-lms-into-a-heterarchy.md

@@ -16,7 +16,7 @@ Lastly, each LM can send motor outputs directly to the motor system. Contrary to
 
 Due to those reasons we call Monty a heterarchical system instead of a hierarchical system. Despite that, we often use terminology as if we did have a conventional hierarchical organization, such as top-down and bottom-up input and lower-level and higher-level LMs.
 
-# Bottom-up Connections
+# Bottom-Up Connections
 
 Connection we refer to as bottom-up connections are connections from SMs to LMs and connections between LMs that communicate an LMs output (the current most likely object ID and pose) to the main input channel of another LM (the current sensed feature and pose). **The output object ID of the sending LM then becomes a feature in the models learned in the receiving LM.** For example, the sending LM might be modeling a tire. When the tire model is recognized, it outputs this and the recognized location and orientation of the tire relative to the body. The receiving LM would not get any information about the 3D structure of the tire from the sending LM. It would only receive the object ID (as a feature) and its pose. This LM could then model a car, composed of different parts. Each part, like the tire, is modeled in detail in a lower-level LM and then becomes a feature in the higher-level LMs' model of the car.
 

docs/how-monty-works/how-learning-modules-work.md

@@ -43,7 +43,7 @@ Each learning module has a buffer class which could be compared to a short term
 
 # The Graph Memory (LTM)
 
-Each learning module has one graph memory class which it uses as a long term memory (LTM) of previously aquired knowledge. In the graph learning modules, the memory stores explicit object models in the form of graphs (represented in the ObjectModel class). The graph memory is responsible for storing, updating, and retrieving models from memory.
+Each learning module has one graph memory class which it uses as a long term memory (LTM) of previously acquired knowledge. In the graph learning modules, the memory stores explicit object models in the form of graphs (represented in the ObjectModel class). The graph memory is responsible for storing, updating, and retrieving models from memory.
 
 ![Graph memory classes and their relationships.](../figures/how-monty-works/gm_classes.png)
 

docs/how-monty-works/learning-module-outputs.md

@@ -30,7 +30,7 @@ Finally, the LM can also **suggest an action in the form of a goal state**. This
 
 There are currently **three flavors of graph matching** implemented: Matching using **displacements**, matching using **features at locations**, and matching using features at locations but with **continuous evidence values for each hypothesis** instead of a binary decision. They all have strengths and weaknesses but are generally successive improvements. They were introduced sequentially as listed above and each iteration was designed to solve problems of the previous one. Currently, we are using the evidence-based approach for all of our benchmark experiments.
 
-**Displacement matching** has the advantage that it **can easily deal with translated, rotated and scaled objects** and recognize them without additional computations for reference frame transforms. If we represent the displacement in a rotation-invariant way (for example as point pair features) the recognition performance is not influenced by the rotation of the object. For scale, we can simply use a scaling factor for the length of the displacements which we can calculate from the difference in length between the first sensed displacement and stored displacemnts of initial hypotheses (assuming we sample a displacement that is stored in the graph, which is a strong assumption). It is the only LM that can deal with scale at the moment. The major downside of this approach is that it **only works if we sample the same displacements that are stored in the graph model** of the object while the number of possible displacements grows explosively with the size of the graph.
+**Displacement matching** has the advantage that it **can easily deal with translated, rotated and scaled objects** and recognize them without additional computations for reference frame transforms. If we represent the displacement in a rotation-invariant way (for example as point pair features) the recognition performance is not influenced by the rotation of the object. For scale, we can simply use a scaling factor for the length of the displacements which we can calculate from the difference in length between the first sensed displacement and stored displacements of initial hypotheses (assuming we sample a displacement that is stored in the graph, which is a strong assumption). It is the only LM that can deal with scale at the moment. The major downside of this approach is that it **only works if we sample the same displacements that are stored in the graph model** of the object while the number of possible displacements grows explosively with the size of the graph.
 
 **Feature matching addresses this sampling issue** of displacement matching by instead matching features at nearby locations in the learned model. The problem with this approach is that locations are not invariant to the rotation of the reference frame of the model. We, therefore, have to cycle through different rotations during matching and apply them to the displacement that is used to query the model. This however is more computationally expensive.
 

docs/how-to-use-monty/running-benchmarks.md

@@ -10,7 +10,7 @@ For more details on the current benchmark experiments, see [this page.](../overv
 
 **When merging a change that impacts the performance on the benchmark experiments, you need to update the table in our documentation [here](../overview/benchmark-experiments.md).**
 
-# How to run a Benchmark Experiment
+# How to Run a Benchmark Experiment
 
 To run a benchmark experiment, simply call
 

docs/how-to-use-monty/tutorials/running-your-first-experiment.md

@@ -105,7 +105,8 @@ If you examine the `MontyExperiment` class, you will also notice that there are
       - Do post-epoch logging.
   - Do post-train logging.
 
-and **this is exactly the procedure that was executed when you ran `python run.py -e first_experiment`.** When we run Monty in evaluation mode, the same sequencce of calls is initiated by `MontyExperiment.evaluate` minus the model updating step in `MontyExperiment.post_episode`. See [here](../../how-monty-works/experiment.md) for more details on epochs, episodes, and steps.
+and **this is exactly the procedure that was executed when you ran `python run.py -e firs
+t_experiment`.** When we run Monty in evaluation mode, the same sequence of calls is initiated by `MontyExperiment.evaluate` minus the model updating step in `MontyExperiment.post_episode`. See [here](../../how-monty-works/experiment.md) for more details on epochs, episodes, and steps.
 
 ## Model
 
@@ -123,7 +124,7 @@ You can, of course, customize step types and when to switch between step types b
 
 **In this particular experiment, `n_train_epochs` was set to 1, and `max_train_steps` was set to 1. This means a single epoch was run, with one matching step per episode**. In the next section, we go up a level from the model step to understand episodes and epochs.
 
-## Data{set, loader}
+## `Data{set, loader}`
 
 In the config for first_experiment, there is a comment that marks the start of data configuration. Now we turn our attention to everything below that line, as this is where episode specifics are defined.
 

docs/how-to-use-monty/tutorials/unsupervised-continual-learning.md

@@ -147,7 +147,7 @@ surf_agent_2obj_unsupervised = dict(
 ```
 If you have read our previous tutorials on [pretraining](pretraining-a-model.md) or [running inference with a pretrained model](running-inference-with-a-pretrained-model.md), you may spot a few differences in this setup. For pretraining, we used the `MontySupervisedObjectPretrainingExperiment` class which also performs training (and not evaluation). While that was a training-only setup, it is different from our unsupervised continual learning config since it supplies object labels to learning modules. For running inference with a pretrained model, we used the `MontyObjectRecognitionExperiment` class but specified that we only wanted to perform evaluation (i.e., `do_train=False` and `do_eval=True`). In contrast, here we used the `MontyObjectRecognitionExperiment` with arguments `do_train=True` and `do_eval=False`. This combination of experiment class and `do_train`/`do_eval` arguments is specific to unsupervised continual learning. We have also increased `min_training_steps`, `object_evidence_threshold`, and `required_symmetry_evidence` to avoid early misclassification when there are fewer objects in memory.
 
-Besides these crucial changes, we have also made a few minor adjustments to simplify the rest of the configs. First, we did not explicitly define our sensor module or motor system configs. This is because we are using `SurfaceAndViewMontyConfig`'s default sensor modules, motor system, and matrices that define connectivity between agents, sensors, and learning modules. Second, we are using a `RandomRotationObjectInitializer` which randomly rotates an object at the beginning of each episode rather than rotating an object by a specific user-defined rotation. Third, we are using the `CSVLoggingConfig`. This is equivalent to setting up a base `LoggingConfig` and specifying that we only want a `BasicCSVStatsHandler`, but it's a bit more succint. Monty has many config classes provided for this kind of convenience.
+Besides these crucial changes, we have also made a few minor adjustments to simplify the rest of the configs. First, we did not explicitly define our sensor module or motor system configs. This is because we are using `SurfaceAndViewMontyConfig`'s default sensor modules, motor system, and matrices that define connectivity between agents, sensors, and learning modules. Second, we are using a `RandomRotationObjectInitializer` which randomly rotates an object at the beginning of each episode rather than rotating an object by a specific user-defined rotation. Third, we are using the `CSVLoggingConfig`. This is equivalent to setting up a base `LoggingConfig` and specifying that we only want a `BasicCSVStatsHandler`, but it's a bit more succinct. Monty has many config classes provided for this kind of convenience.
 
 # Running the Unsupervised Continual Learning Experiment
 

docs/overview/benchmark-experiments.md

@@ -4,7 +4,7 @@ description: Performance of current implementation on our benchmark test suite.
 ---
 # Object and Pose Recognition on the YCB Dataset
 
-## What do we Test?
+## What Do We Test?
 
 We split up the experiments into a short benchmark test suite and a long one. The short suite tests performance on a subset of 10 out of the 77 [YCB](https://www.ycbbenchmarks.com/) objects which allows us to assess performance under different conditions more quickly. Unless otherwise indicated, the 10 objects are chosen to be distinct in morphology and models are learned using the surface agent, which follows the object surface much like a finger. 
 
@@ -115,7 +115,7 @@ An object is classified as detected correctly if the detected object ID is in th
 | surf_agent_unsupervised_10distinctobj_noise | 80.00%               | 67.78%                 | 1.09                   | 2.78                   | 22m      | 13s                  |
 | surf_agent_unsupervised_10simobj            | 50.00%               | 76.67%                 | 2.75                   | 2.20                   | 25m      | 15s                  |
 
-To obtain these results use `print_unsupervised_stats(train_stats, epoch_len=10)` (wandb logging is currently not written for unsupervised stats). Unsupervised, continual learning can, by definition, not be parallelized accross epochs. Therefore these experiments were run without multiprocessing on the laptop (running on cloud CPUs works as well but since these are slower without parallelization these were run on the laptop).
+To obtain these results use `print_unsupervised_stats(train_stats, epoch_len=10)` (wandb logging is currently not written for unsupervised stats). Unsupervised, continual learning can, by definition, not be parallelized across epochs. Therefore these experiments were run without multiprocessing on the laptop (running on cloud CPUs works as well but since these are slower without parallelization these were run on the laptop).
 
 # Monty-Meets-World
 

docs/overview/vision-of-the-thousand-brains-project/capabilities-of-the-system.md

@@ -7,7 +7,7 @@ Even though we cannot predict the ultimate use cases of the system, we want to t
 
 Following is a list of capabilities that we are always thinking about when designing and implementing the system. We are not looking for point solutions for each of these problems but a general algorithm that can solve them all. It is by no means a comprehensive list but should give an idea of the scope of the system.
 
-### Capabilities That our System Already Has (At Least to a Certain Extent):
+### Capabilities That Our System Already Has (At Least to a Certain Extent):
 
 - Recognizing objects independent of their location and orientation in the world.
 
@@ -21,7 +21,7 @@ Following is a list of capabilities that we are always thinking about when desig
 
 - Recognizing objects when they are partially occluded by other objects.
 
-### Further Capabilities That we are Currently Working on:
+### Further Capabilities That we Are Currently Working On:
 
 - Learning categories of objects and generalizing to new instances of a category.