You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using this ticket to take notes on further updates for v2 emergent.
While the etime.Train, TestTrialEpoch etc enums work well for many cases, sometimes they just don't fit, and it just seems very bad to have to shoe-horn into these predefined values. And all the redundant functions taking Scope inputs etc is bad. A better solution would be to just have the sim define its own enums (there are just a few -- would be copied boilerplate but still explicit), and all the standard code uses enums.Enum for everything. The ccnsims stroop model is a good illustration of this issue: had to use Validate for the SOA test case. In general, the no. 1 lesson is to have good simple interfaces that all the general library stuff consumes, instead of requiring specific types.
The looper GUI controls become increasingly unwieldy as you have more "Modes" beyond just Train and Test. Also the Init function needs to be somehow built into these controls -- otherwise it ends up being tacked on at the start or end. Soln: have a mode enum at the start, that should be rendered with the nice segmented button thing, that you click to set the mode, and have an integrated Init button that is also mode sensitive and takes a func pointer to actually perform the init functionality beyond the looper. Again stroop broke this paradigm.
In general, it would be good to revisit the looper api and make things simpler and more transparent, and provide good cheat sheet API docs -- I am always forgetting how to do stuff. Also, having things implicitly shared across loops in some cases is very bad -- it should never share across Stacks. And rename Stacks -> Modes so it is more clear what a stack is.
elog will be significantly updated based on the datafs framework, and estats will be replaced entirely by datafs and the updated tensor framework. Using goal, it should be possible for everything to be much simpler and more directly implemented so you can easily see how to compute your own stats at every step. The model of a single log item that generates everything across modes and levels is good for consolidating all the logic in one place, but is too magical -- needs to be more explicit. e.g., use a vararg list of modes instead of AllModes magic, which then entails all the NoPlot stuff. With datafs replacing the magical ctx context, hopefully everything is clearer -- need good goal code to make all that super clear, concise and efficient. Also absolutely need the plotting Option stuff specified cleanly with struct values: using closures like styler? If need to refer to a given stat in multiple places (e.g., for control) then use enums as a convention so that you're not typing string key names everywhere. But ideally most stats are specified exactly once in a monolithic closure that computes the value directly from the network and does all the aggregation, all in one switch statement organized by time scale. Run it once to create the values during Init? use Recycle logic? not clear about some of these things..
params don't use a string value. Does it need to be any or perhaps it should be a more constrained interface type, that can either be bool or float32 or enums.Enum? It would be good to constrain -- no strings actually used in real params! everything must be GPU compatible, but params remains CPU-side only.
The text was updated successfully, but these errors were encountered:
@kkoreilly reminded me that params are basically the same as styles in cogent core, and the same conclusion applies: the only way to cleanly get a direct tab-completable path into a nested structured object and set a value directly as a value is using closures (Stylers in core). So this is what we have to do in params. Getting away from the whole struct literal syntax will be nice too.
Furthermore, there is a notional plan of CoCo configuration system that also integrates yaegi interpretable code and goal transpiling to produce the best ever config file syntax. This would be for Config etc. So probably we want to go down that path first. Remains to be seen how this applies to the plot config stuff but probably.
I'm using this ticket to take notes on further updates for v2 emergent.
While the
etime.Train
,Test
Trial
Epoch
etc enums work well for many cases, sometimes they just don't fit, and it just seems very bad to have to shoe-horn into these predefined values. And all the redundant functions taking Scope inputs etc is bad. A better solution would be to just have the sim define its own enums (there are just a few -- would be copied boilerplate but still explicit), and all the standard code usesenums.Enum
for everything. The ccnsimsstroop
model is a good illustration of this issue: had to useValidate
for theSOA
test case. In general, the no. 1 lesson is to have good simple interfaces that all the general library stuff consumes, instead of requiring specific types.The
looper
GUI controls become increasingly unwieldy as you have more "Modes" beyond just Train and Test. Also the Init function needs to be somehow built into these controls -- otherwise it ends up being tacked on at the start or end. Soln: have a mode enum at the start, that should be rendered with the nice segmented button thing, that you click to set the mode, and have an integrated Init button that is also mode sensitive and takes a func pointer to actually perform the init functionality beyond the looper. Again stroop broke this paradigm.In general, it would be good to revisit the
looper
api and make things simpler and more transparent, and provide good cheat sheet API docs -- I am always forgetting how to do stuff. Also, having things implicitly shared across loops in some cases is very bad -- it should never share across Stacks. And rename Stacks -> Modes so it is more clear what a stack is.elog
will be significantly updated based on thedatafs
framework, andestats
will be replaced entirely bydatafs
and the updated tensor framework. Usinggoal
, it should be possible for everything to be much simpler and more directly implemented so you can easily see how to compute your own stats at every step. The model of a single log item that generates everything across modes and levels is good for consolidating all the logic in one place, but is too magical -- needs to be more explicit. e.g., use a vararg list of modes instead of AllModes magic, which then entails all the NoPlot stuff. Withdatafs
replacing the magicalctx
context, hopefully everything is clearer -- need goodgoal
code to make all that super clear, concise and efficient. Also absolutely need the plotting Option stuff specified cleanly with struct values: using closures like styler? If need to refer to a given stat in multiple places (e.g., for control) then use enums as a convention so that you're not typing string key names everywhere. But ideally most stats are specified exactly once in a monolithic closure that computes the value directly from the network and does all the aggregation, all in one switch statement organized by time scale. Run it once to create the values during Init? use Recycle logic? not clear about some of these things..params
don't use a string value. Does it need to beany
or perhaps it should be a more constrained interface type, that can either bebool
orfloat32
orenums.Enum
? It would be good to constrain -- no strings actually used in real params! everything must be GPU compatible, but params remains CPU-side only.The text was updated successfully, but these errors were encountered: