Open rcoreilly opened 1 day ago
@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. The nillable type Option thing is key here.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.