README
¶
Docs: GoDoc
See Wiki Params page for detailed docs.
Package netparams provides general-purpose parameter management functionality for organizing multiple sets of parameters efficiently, and basic IO for saving / loading from JSON files and generating Go code to embed into applications, and a basic GUI for viewing and editing.
netparams is a simplification of params focused only on setting Network params -- eliminating the params.Set and params.Sheets levels that support setting params on arbitrary non-Network objects. It is better to use econfig to configure standard struct Config objects outside of the Network -- the styling flexibility is really only needed for Network level params.
The netparams.Sets contains one or more params.Sheets (akin to CSS style sheets) that constitute a coherent set of parameters. Here's the structure:
Sets {
"Base": {
Sel: "Layer" {
Params: {
"Layer.Inhib.Layer.Gi": "1.1",
...
}
},
Sel: ".Back" {
Params: {
"Prjn.PrjnScale.Rel": "0.2",
...
}
}
},
}
The default supported organization is to have a "Base" Set that has all the best parameters so far, and then other sets can modify specific params relative to that one. Order of application is critical, as subsequent params applications overwrite earlier ones, and the typical order is:
Defaults()method called that establishes the hard-coded default parameters.- Then apply "Base"
params.Sheetfor any changes relative to those. - Then optionally apply one or more additional
params.Sheets with current experimental parameters or for other special use-cases.
Critically, all of this is entirely up to the particular model program(s) to determine and control -- this package just provides the basic data structures for holding all of the parameters, and the IO / and Apply infrastructure.
Each params.Sheet consists of a collection of params.Sel elements which finally contain the parameters. The Sel field specifies a CSS-style selector determining over what scope the parameters should be applied:
-
Type(no prefix) = name of a type -- anything having this type name will get these params. -
.Class= anything with a given class label (each object can have multiple Class labels and thus receive multiple parameter settings, but again, order matters!) -
#Name= a specific named object.
The order of application within a given Sheet is also critical -- typically put the most general Type params first, then .Class, then the most specific #Name cases, to achieve within a given Sheet the same logic of establishing Base params for all types and then more specific overrides for special cases (e.g., an overall learning rate that appplies across all projections, but maybe a faster or slower one for a .Class or specific #Name'd projection).
There is a params.Styler interface with methods that any Go type can implement to provide these different labels. The emer.Network, .Layer, and .Prjn interfaces each implement this interface.
Parameter values are stored as strings, which can represent any value.
Finally, there are methods to show where params.Sheet sets the same parameter differently, and to compare with the default settings on a given object type using go struct field tags of the form def:"val1[,val2...]".
Providing direct access to specific params
The best way to provide the user direct access to specific parameter values through the Params mechanisms is to put the relevant params in the Sim object, where they will be editable fields, and then call SetFloat or SetString as appropriate with the path to the parameter in question, followed by a call to apply the params.
The current value can be obtained by the ParamVal methods.
Documentation
¶
Overview ¶
Package params provides general-purpose parameter management functionality for organizing multiple sets of parameters efficiently, and basic IO for saving / loading from JSON files and generating Go code to embed into applications, and a basic GUI for viewing and editing.
The main overall unit that is generally operated upon at run-time is the params.Set, which is a collection of params.Sheet's (akin to CSS style sheets) that constitute a coherent set of parameters.
A good strategy is to have a "Base" Set that has all the best parameters so far, and then other sets can modify specific params relative to that one. Order of application is critical, as subsequent params applications overwrite earlier ones, and the typical order is:
- Defaults() method called that establishes the hard-coded default parameters.
- Then apply "Base" params.Set for any changes relative to those.
- Then optionally apply one or more additional params.Set's with current experimental parameters.
Critically, all of this is entirely up to the particular model program(s) to determine and control -- this package just provides the basic data structures for holding all of the parameters, and the IO / and Apply infrastructure.
Within a params.Set, multiple different params.Sheet's can be organized, with each CSS-style sheet achieving a relatively complete parameter styling of a given element of the overal model, e.g., "Network", "Sim", "Env". Or Network could be further broken down into "Learn" vs. "Act" etc, or according to different brain areas ("Hippo", "PFC", "BG", etc). Again, this is entirely at the discretion of the modeler and must be performed under explict program control, especially because order is so critical.
Each params.Sheet consists of a collection of params.Sel elements which actually finally contain the parameters. The Sel field specifies a CSS-style selector determining over what scope the parameters should be applied:
* Type = name of a type -- anything having this type name will get these params.
* .Class = anything with a given class label (each object can have multiple Class labels and thus receive multiple parameter settings, but again, order matters!)
* #Name = a specific named object.
The order of application within a given Sheet is also critical -- typically put the most general Type params first, then .Class, then the most specific #Name cases, to achieve within a given Sheet the same logic of establishing Base params for all types and then more specific overrides for special cases (e.g., an overall learning rate that appplies across all projections, but maybe a faster or slower one for a .Class or specific #Name'd projection).
There is a params.Styler interface with methods that any Go type can implement to provide these different labels. The emer.Network, .Layer, and .Prjn interfaces each implement this interface.
Otherwise, the Apply method will just directly apply params to a given struct type if it does not implement the Styler interface.
Parameter values are limited to float64 values *only*. These can be specified using "enum" style const integer values, and can be applied to any numeric type (they will be automatically converted), but internally this is the only parameter value type, which greatly simplifies the overall interface, and handles the vast majority of use-cases (especially because named options are just integers and can be set as such).
Finally, there are methods to show where params.Set's set the same parameter differently, and to compare with the default settings on a given object type using go struct field tags of the form default:"val1[,val2...]".
Index ¶
- func WriteGoPrelude(w io.Writer, varNm string)
- type Sets
- func (ps *Sets) DiffsAll() string
- func (ps *Sets) DiffsFirst() string
- func (ps *Sets) DiffsWithin(sheetName string) string
- func (pr *Sets) OpenJSON(filename core.Filename) error
- func (pr *Sets) OpenTOML(filename core.Filename) error
- func (ps *Sets) ParamValue(sheet, sel, param string) (string, error)
- func (pr *Sets) SaveGoCode(filename core.Filename) error
- func (pr *Sets) SaveJSON(filename core.Filename) error
- func (pr *Sets) SaveTOML(filename core.Filename) error
- func (ps *Sets) SetFloat(sheet, sel, param string, val float64) error
- func (ps *Sets) SetString(sheet, sel, param string, val string) error
- func (ps *Sets) SheetByName(name string) *params.Sheet
- func (ps *Sets) SheetByNameTry(name string) (*params.Sheet, error)
- func (pr *Sets) StringGoCode() []byte
- func (pr *Sets) WriteGoCode(w io.Writer, depth int)
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func WriteGoPrelude ¶
WriteGoPrelude writes the start of a go file in package main that starts a variable assignment to given variable -- for start of SaveGoCode methods.
Types ¶
type Sets ¶
Sets is a collection of Sheets that can be chosen among depending on different desired configurations etc. Thus, each Set represents a collection of different possible specific configurations, and different such configurations can be chosen by name to apply as desired.
func (*Sets) DiffsAll ¶
DiffsAll reports all the cases where the same param path is being set to different values across different sets
func (*Sets) DiffsFirst ¶
DiffsFirst reports all the cases where the same param path is being set to different values between the "Base" sheet and all other sheets. Only works if there is a sheet named "Base".
func (*Sets) DiffsWithin ¶
DiffsWithin reports all the cases where the same param path is being set to different values within different sheets in given sheet
func (*Sets) ParamValue ¶
ParamVal returns the value of given parameter, in selection sel, in sheet and set. Returns error if anything is not found.
func (*Sets) SaveGoCode ¶
SaveGoCode saves params to corresponding Go initializer code.
func (*Sets) SetFloat ¶
SetFloat sets the value of given parameter, in selection sel, in sheet and set.
func (*Sets) SetString ¶
SetString sets the value of given parameter, in selection sel, in sheet and set. Returns error if anything is not found.
func (*Sets) SheetByName ¶
SheetByName returns given sheet by name -- for use when confident that it exists, as a nil will return if not found with no error
func (*Sets) SheetByNameTry ¶
SheetByNameTry tries to find given set by name, and returns error if not found (also logs the error)
func (*Sets) StringGoCode ¶
StringGoCode returns Go initializer code as a byte string.
Source Files