fix ly hyphen grammar mistake and other spelling mistakes

README.md

@@ -9,9 +9,9 @@ This is the new home of the *emergent* neural network simulation software, devel
 
 See [Wiki Install](https://github.com/emer/emergent/wiki/Install) for installation instructions (note: Go 1.18 required), and the [Wiki Rationale](https://github.com/emer/emergent/wiki/Rationale) and [History](https://github.com/emer/emergent/wiki/History) pages for a more detailed rationale for the new version of emergent, and a history of emergent (and its predecessors).
 
-The single clearest motivation for using Go vs. the ubiquitous Python, is that Python is too slow to implement the full computational model: it can only serve as a wrapper around backend code which is often written in C or C++.  By contrast, *Go can implement the entire model* in one coherent language.  This, along with the advantages of the strongly typed, rapidly compiled Go language vs. duck typed Python for developing large scale frameworks, and the many other benefits of the Go language environment for reproducible, reliable builds across platforms, results in a satisfying and productive programming experience.  Note also that we are not able to leverage existing Python backends such as PyTorch or TensorFlow due to the unique demands of biologically-based neural models.
+The single clearest motivation for using Go vs. the ubiquitous Python, is that Python is too slow to implement the full computational model: it can only serve as a wrapper around backend code which is often written in C or C++.  By contrast, *Go can implement the entire model* in one coherent language.  This, along with the advantages of the strongly typed, rapidly compiled Go language vs. duck typed Python for developing large scale frameworks, and the many other benefits of the Go language environment for reproducible, reliable builds across platforms, results in a satisfying and productive programming experience.  Note also that we are not able to leverage existing Python backends such as PyTorch or TensorFlow due to the unique demands of biologically based neural models.
 
-See the [ra25 example](https://github.com/emer/leabra/blob/master/examples/ra25/README.md) in the `leabra` package for a complete working example (intended to be a good starting point for creating your own models), and any of the 26 models in the [Comp Cog Neuro sims](https://github.com/CompCogNeuro/sims) repository which also provide good starting points.  See the [etable wiki](https://github.com/emer/etable/v2/wiki) for docs and example code for the widely-used etable data table structure, and the `family_trees` example in the CCN textbook sims which has good examples of many standard network representation analysis techniques (PCA, cluster plots, RSA).
+See the [ra25 example](https://github.com/emer/leabra/blob/master/examples/ra25/README.md) in the `leabra` package for a complete working example (intended to be a good starting point for creating your own models), and any of the 26 models in the [Comp Cog Neuro sims](https://github.com/CompCogNeuro/sims) repository which also provide good starting points.  See the [etable wiki](https://github.com/emer/etable/v2/wiki) for docs and example code for the widely used etable data table structure, and the `family_trees` example in the CCN textbook sims which has good examples of many standard network representation analysis techniques (PCA, cluster plots, RSA).
 
 See [python README](https://github.com/emer/leabra/blob/master/python/README.md) and [Python Wiki](https://github.com/emer/emergent/wiki/Python) for info on using Python to run models.  See [eTorch](https://github.com/emer/etorch) for how to get an interactive 3D NetView for PyTorch models.
 
@@ -29,7 +29,7 @@ See [python README](https://github.com/emer/leabra/blob/master/python/README.md)
 
 # Key Features
 
-* Currently focused exclusively on implementing the biologically-based `Leabra` algorithm, which is not at all suited to implementation in current popular neural network frameworks such as `PyTorch`.  Leabra uses point-neurons and competitive inhibition, and has sparse activity levels and ubiquitous fully recurrent bidirectional processing, which enable / require novel optimizations for how simulated neurons communicate, etc.
+* Currently focused exclusively on implementing the biologically based `Leabra` algorithm, which is not at all suited to implementation in current popular neural network frameworks such as `PyTorch`.  Leabra uses point-neurons and competitive inhibition, and has sparse activity levels and ubiquitous fully recurrent bidirectional processing, which enable / require novel optimizations for how simulated neurons communicate, etc.
 
 * Go-based code can be compiled to run entire models.  Instead of creating and running everything in the *emergent* GUI, the process is much more similar to how e.g., PyTorch and other current frameworks work.  You write code to configure your model, and directly call functions that run your model, etc.  This gives you full, direct, transparent control over everything that happens in your model, as opposed to the previous highly opaque nature of [C++ emergent](https://github.com/emer/cemer).
 
@@ -43,7 +43,7 @@ See [python README](https://github.com/emer/leabra/blob/master/python/README.md)
 
 # Design / Organization
 
-* The `emergent` repository contains a collection of packages supporting the implementation of biologically-based neural networks.  The main package is `emer` which specifies a minimal abstract interface for a neural network.  The `etable` `etable.Table` data structure (DataTable in C++) is in a separate repository under the overall `emer` project umbrella, as are specific algorithms such as `leabra` which implement the `emer` interface.
+* The `emergent` repository contains a collection of packages supporting the implementation of biologically based neural networks.  The main package is `emer` which specifies a minimal abstract interface for a neural network.  The `etable` `etable.Table` data structure (DataTable in C++) is in a separate repository under the overall `emer` project umbrella, as are specific algorithms such as `leabra` which implement the `emer` interface.
 
 * Go uses `interfaces` to represent abstract collections of functionality (i.e., sets of methods).  The `emer` package provides a set of interfaces for each structural level (e.g., `emer.Layer` etc) -- any given specific layer must implement all of these methods, and the structural containers (e.g., the list of layers in a network) are lists of these interfaces.  An interface is implicitly a *pointer* to an actual concrete object that implements the interface.
 

decoder/softmax.go

@@ -22,7 +22,7 @@ import (
 )
 
 // SoftMax is a softmax decoder, which is the best choice for a 1-hot classification
-// using the widely-used SoftMax function: https://en.wikipedia.org/wiki/Softmax_function
+// using the widely used SoftMax function: https://en.wikipedia.org/wiki/Softmax_function
 type SoftMax struct {
 
 	// learning rate

doc.go

@@ -12,7 +12,7 @@ into the following sub-repositories:
 * emer: defines the primary structural interfaces for emergent, at the level of
 Network, Layer, and Prjn (projection).  These contain no algorithm-specific code
 and are only about the overall structure of a network, sufficient to support general
-purpose tools such as the 3D NetView.  It also houses widely-used support classes used
+purpose tools such as the 3D NetView.  It also houses widely used support classes used
 in algorithm-specific code, including things like MinMax and AvgMax, and also the
 parameter-styling infrastructure (emer.Params, emer.ParamStyle, emer.ParamSet and
 emer.ParamSets).

elog/README.md

@@ -6,7 +6,7 @@ Docs: [GoDoc](https://pkg.go.dev/github.com/emer/emergent/elog)
 
 The `elog.Item` provides a full definition of each distinct item that is logged with a map of Write functions keyed by a scope string that reflects the time scale and mode.  The same function can be used across multiple scopes, or a different function for each scope, etc.
 
-The Items are written to the table *in the order added*, so you can take advantage of previously-computed item values based on the actual ordering of item code.  For example, intermediate values can be stored / retrieved from Stats, or from other items on a log, e.g., using `Context.LogItemFloat` function.
+The Items are written to the table *in the order added*, so you can take advantage of previously computed item values based on the actual ordering of item code.  For example, intermediate values can be stored / retrieved from Stats, or from other items on a log, e.g., using `Context.LogItemFloat` function.
 
 The Items are then processed in `CreateTables()` to create a set of `etable.Table` tables to hold the data.
 

elog/context.go

@@ -24,7 +24,7 @@ type WriteFunc func(ctx *Context)
 // Context provides the context for logging Write functions.
 // SetContext must be called on Logs to set the Stats and Net values
 // Provides various convenience functions for setting log values
-// and other commonly-used operations.
+// and other commonly used operations.
 type Context struct {
 
 	// pointer to the Logs object with all log data

env/README.md

@@ -22,7 +22,7 @@ The `EnvDesc` interface provides additional methods (originally included in `Env
 
 The `Step` should update all relevant state elements as appropriate, so these can be queried by the user. Particular paradigms of environments must establish naming conventions for these state elements which then allow the model to use the information appropriately -- the Env interface only provides the most basic framework for establishing these paradigms, and ultimately a given model will only work within a particular paradigm of environments following specific conventions.
 
-See e.g., env.FixedTable for particular implementation of a fixed Table of patterns, for one example of a widely-used paradigm.
+See e.g., env.FixedTable for particular implementation of a fixed Table of patterns, for one example of a widely used paradigm.
 
 Typically each specific implementation of this Env interface will have multiple parameters etc that can be modified to control env behavior -- all of this is paradigm-specific and outside the scope of this basic interface.
 

env/doc.go

@@ -41,7 +41,7 @@ model will only work within a particular paradigm of environments following
 specific conventions.
 
 See e.g., env.FixedTable for particular implementation of a fixed Table
-of patterns, for one example of a widely-used paradigm.
+of patterns, for one example of a widely used paradigm.
 
 Typically each specific implementation of this Env interface will have
 multiple parameters etc that can be modified to control env behavior --

netview/netdata.go

@@ -623,7 +623,7 @@ func (nd *NetData) WriteJSON(w io.Writer) error {
 // }
 
 // PlotSelectedUnit opens a window with a plot of all the data for the
-// currently-selected unit.
+// currently selected unit.
 // Useful for replaying detailed trace for units of interest.
 func (nv *NetView) PlotSelectedUnit() (*etable.Table, *eplot.Plot2D) { //types:add
 	nd := &nv.Data
@@ -662,7 +662,7 @@ func (nv *NetView) PlotSelectedUnit() (*etable.Table, *eplot.Plot2D) { //types:a
 }
 
 // SelectedUnitTable returns a table with all of the data for the
-// currently-selected unit, and data parallel index.
+// currently selected unit, and data parallel index.
 func (nd *NetData) SelectedUnitTable(di int) *etable.Table {
 	if nd.PrjnLay == "" || nd.PrjnUnIndex < 0 {
 		fmt.Printf("NetView:SelectedUnitTable -- no unit selected\n")